From vishwas.ietf@gmail.com Sun Jan 1 15:21:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2051B11E808A for ; Sun, 1 Jan 2012 15:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgMf87C182va for ; Sun, 1 Jan 2012 15:21:48 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C51B11E8080 for ; Sun, 1 Jan 2012 15:21:48 -0800 (PST) Received: by obcuz6 with SMTP id uz6so13037555obc.31 for ; Sun, 01 Jan 2012 15:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bOXkUHZcCGHD0HnU+dlmSe87ci347pvCLRDhsr/h7AE=; b=qkJqQFYK5jE2fYaIZBG5KnMK6YyNM8DZM+6k2bdWiYBGD5srtOtP5PRCDvcom8a5ey tuU8sT7UzX4sSeq2kVaHubNyNfEwhWa9wRJazuSRRGFU2VZUKQfNf9IimSEyLP+a5Zky GAR3Zns/DOWlIbgrmkFmb9wVBG8frIHSjCqic= MIME-Version: 1.0 Received: by 10.182.202.69 with SMTP id kg5mr40398739obc.35.1325460106722; Sun, 01 Jan 2012 15:21:46 -0800 (PST) Received: by 10.182.51.105 with HTTP; Sun, 1 Jan 2012 15:21:46 -0800 (PST) In-Reply-To: <4EF7D880.3090102@gont.com.ar> References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> Date: Sun, 1 Jan 2012 15:21:46 -0800 Message-ID: Subject: Re: Fragmentation-related security issues From: Vishwas Manral To: Fernando Gont Content-Type: multipart/alternative; boundary=e89a8f6438c2d33b9504b57fba1e Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 23:21:49 -0000 --e89a8f6438c2d33b9504b57fba1e Content-Type: text/plain; charset=ISO-8859-1 Hi Fernando, I did qyuite some work on "Tiny Fragments" for IPv6 a while back. We seem to be having the same set of discussions over again. http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-03 The draft seemed to have been well received, but never got back to taking it to completetion. Let me know what you think of the work. Thanks, Vishwas On Sun, Dec 25, 2011 at 6:14 PM, Fernando Gont wrote: > Hi, Brian, > > On 12/24/2011 05:06 PM, Brian E Carpenter wrote: > >>>> That aside, I don't know whether e.g. NAT64 or the like used this > >>>> (.e.g, whether they are used for transition technologies as envisioned > >>>> in RFC 2460). However, it might also be the case that such "atomic > >>>> fragments" are generated when communicating through networks that do > >>>> not really have a MTU >= 1280. In such scenarios there might be some > >>>> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU > >>>> smaller than 1280, thus resulting in atomic fragments (such that it's > >>>> easier for the "gateway" to fragment the IPv6 packets). > >>> Yes, this seems a plausible explanation. I wouldn't consider this > >>> actual use, rather network misconfiguration. > >> > >> Why? > > > > MTU <1280 is a complete breach of the IPv6 standard, so it is by > > definition a misconfiguration. > > Well, as long as communication does work without requiring the sending > node to fragment packets to < 1280, the standard is not being "broken". > > In the scenario I was describing, the underlying reason for receiving an > ICMPv6 PTB <1280 might be a network that doesn't support an MTU >= 1280 > (and hence, that violates the standard). However, that's irrelevant as > long as the sending host is not required to fragment to <1280 for > communication to work. > > That aside, from my perspecitive std violation != misconfiguration. A > misconfiguration is probably the result of an error (probably on the > side of the administrator), while an std violation such as the one that > we're possibly talking about is most likely the result of a deliverate > action (which is probably not going to be fixed even if it's reported). > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > --e89a8f6438c2d33b9504b57fba1e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Fernando,
=A0
I did qyuite some work on "Tiny Fragments" for IPv6 a while = back. We seem to be having the same set of discussions over again.
=A0
The draft seemed to have been well received, but never got back to tak= ing it to completetion. Let me know what you think of the work.
=A0
Thanks,
Vishwas
On Sun, Dec 25, 2011 at 6:14 PM, Fernando Gont <= span dir=3D"ltr"><fernando@gont.= com.ar> wrote:
Hi, Brian,

On 12/24/2011 05:06 PM, Brian E Carpenter wrote:
&= gt;>>> That aside, I don't know whether e.g. NAT64 or the like= used this
>>>> (.e.g, whether they are used for transition = technologies as envisioned
>>>> in RFC 2460). However, it might also be the case that such= "atomic
>>>> fragments" are generated when commun= icating through networks that do
>>>> not really have a MTU = >=3D 1280. In such scenarios there might be some
>>>> for of gateway that sends the ICMPv6 PTB advertising a Nex= t-Hop MTU
>>>> smaller than 1280, thus resulting in atomic f= ragments (such that it's
>>>> easier for the "gatew= ay" to fragment the IPv6 packets).
>>> Yes, this seems a plausible explanation. =A0I wouldn't con= sider this
>>> actual use, rather network misconfiguration.
= >>
>> Why?
>
> MTU <1280 is a complete breach= of the IPv6 standard, so it is by
> definition a misconfiguration.

Well, as long as communica= tion does work without requiring the sending
node to fragment packets to= < 1280, the standard is not being "broken".

In the sce= nario I was describing, the underlying reason for receiving an
ICMPv6 PTB <1280 might be a network that doesn't support an MTU >= =3D 1280
(and hence, that violates the standard). However, that's ir= relevant as
long as the sending host is not required to fragment to <= 1280 for
communication to work.

That aside, from my perspecitive std violatio= n !=3D misconfiguration. A
misconfiguration is probably the result of an= error (probably on the
side of the administrator), while an std violati= on such as the one that
we're possibly talking about is most likely the result of a deliverate<= br>action (which is probably not going to be fixed even if it's reporte= d).

Thanks,
--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F= 1C9 3945 96EE A9EF D076 FFF1

--e89a8f6438c2d33b9504b57fba1e-- From bzeeb-lists@lists.zabbadoz.net Mon Jan 2 14:11:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFD121F84B9 for ; Mon, 2 Jan 2012 14:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.37 X-Spam-Level: X-Spam-Status: No, score=-1.37 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_20=-0.74, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftjim4UT8VSH for ; Mon, 2 Jan 2012 14:11:04 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 84EBE21F84A7 for ; Mon, 2 Jan 2012 14:11:03 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8D93925D3870; Mon, 2 Jan 2012 22:11:01 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id B8D02BD857A; Mon, 2 Jan 2012 22:11:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id rpEylbn1KY3A; Mon, 2 Jan 2012 22:10:58 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B09B4BD857B; Mon, 2 Jan 2012 22:10:56 +0000 (UTC) Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20111220.124458.41706285.sthaug@nethelp.no> Date: Mon, 2 Jan 2012 22:10:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:11:04 -0000 On 20. Dec 2011, at 11:44 , sthaug@nethelp.no wrote: Hey, I guess I should follow-up on this one. >>> IPv6 allows packets to contain a Fragment Header, without the = packet >>> being actually fragmented into multiple pieces. Such packets >>> typically result from hosts that have received an ICMPv6 "Packet = Too >>> Big" error message that advertises a "Next-Hop MTU" smaller than = 1280 >>> bytes, and are currently processed by hosts as "fragmented >>> traffic". >>=20 >> Does such traffic actually occur in the wild, or would it only be = used >> in attacks? >=20 > Such traffic absolutely occurs in the wild. I have three reasonably > busy name servers where this is logged as an error from the ipfw code, > e.g. and I know of a couple of more people who have seen it and have ways to trigger it with legitimate servers. I have never tracked things down in more detail at some point back. > Dec 16 14:04:04 slem kernel: IPFW2: IPV6 - Invalid Fragment Header > ... > This is because these name servers haven't (yet) been upgraded to a > FreeBSD version where bug report kern/145733 haven't been fixed. It > *is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE. And given I am responsible for both committing the original "block" and the relaxed version let me elaborate a bit on this: Contrary to how a lot of people seem to read RFC 2460, especially the = last paragraph of section 5 (also subject to Florian's Errata 2843), I = basically read (in) the past: 4.5 "The Fragment header is used by an IPv6 source to send a packet = larger than would fit in the path MTU to its destination." =20 ``You shall not add a fragment header unless you really need to''. The only way you must add a fragment header for a packet size below 1280 = is when it is a packet going to a v4 destination (i.e. say through NAT64 = these days). How you can track this (if you can) and how you get that = information is beyond the scope of 2460 but you need to know to be able to. = Otherwise you shall not. This is the reason ipfw originally dropped what people now seem to call "atomic fragments". When I PR started to look at the PR I consulted briefly with Bob and the outcome of the short exchange for me was: - the "atomic frags" do not seem to hurt in this particular filtering = case and could possibly be allowed. - I prepared an errata text suggesting that the text in 4.5 was = clarified allowing "atomic frags" but discouraging their usage, especially given aforementioned errata threatens to remove the paragraph from section = 5, which is the only real reason people seem to think they are valid. While I still feel that these "atomic frags" should be sent to the = packet shredder on first sight it seemed to match reality (and especially operational impact) better. However I left a sysctl for individuals to control their preference. Another thing on the "atomic frags" I was (partly) shown was that they = seemed to have a length in the 50 octets size which would even be way below = other minimums. So I am really not feeling too confident that it's not just = silly stacks or software bugs and it would really be thrilling if people could = figure out OS and version and reason why some systems send them. On the entire "fragmentation related security issues" topic, I feel we = are seriously heading into wrong directions to just more complications = rather than simplifications. The idea of having the fragment offset to stay compatible the way things = worked in IPv4 certainly was a great idea and has later proven to be a PITA. = What I'd really like to have is a silly fragment counter 1..n, so no overlapping = possible (and not just not allowed on paper anymore as that does not remove that = code to check from the stacks), simple handling of duplicate fragments, and = no "atomic frags" allowed. Luckily the fragment header still has a lot of spare space that could = allow to indicate which scheme is used and dropping a packet unless a bit is = set (not being set indicating the old scheme) is really easy to implement, = esp. after a transition period and ripping the old code out would be as well = then;-) I 'd really not want to add even more complicated house keeping and = stuff long term. /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!= From sthaug@nethelp.no Mon Jan 2 14:16:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73AFE21F8AA9 for ; Mon, 2 Jan 2012 14:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgaypVMDLL+9 for ; Mon, 2 Jan 2012 14:16:20 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 701C021F84B9 for ; Mon, 2 Jan 2012 14:16:19 -0800 (PST) Received: (qmail 80282 invoked from network); 2 Jan 2012 22:16:16 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 2 Jan 2012 22:16:16 -0000 Date: Mon, 02 Jan 2012 23:16:16 +0100 (CET) Message-Id: <20120102.231616.74700645.sthaug@nethelp.no> To: bzeeb-lists@lists.zabbadoz.net Subject: Re: Fragmentation-related security issues From: sthaug@nethelp.no In-Reply-To: References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:16:20 -0000 > >> Does such traffic actually occur in the wild, or would it only be used > >> in attacks? > > > > Such traffic absolutely occurs in the wild. I have three reasonably > > busy name servers where this is logged as an error from the ipfw code, > > e.g. > > and I know of a couple of more people who have seen it and have ways to > trigger it with legitimate servers. I have never tracked things down > in more detail at some point back. If anybody would like to track down this, I can supply pcap data. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From bzeeb-lists@lists.zabbadoz.net Mon Jan 2 14:49:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417CA1F0C51 for ; Mon, 2 Jan 2012 14:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ5DtuEq18dm for ; Mon, 2 Jan 2012 14:49:06 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id BB9E41F0C4D for ; Mon, 2 Jan 2012 14:49:06 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 17A6225D37C7; Mon, 2 Jan 2012 22:49:04 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2282CBD8583; Mon, 2 Jan 2012 22:49:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id JQIBPZEKbXpl; Mon, 2 Jan 2012 22:49:03 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 61B66BD8582; Mon, 2 Jan 2012 22:48:56 +0000 (UTC) Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120102.231616.74700645.sthaug@nethelp.no> Date: Mon, 2 Jan 2012 22:48:55 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> To: sthaug@nethelp.no X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 22:49:07 -0000 On 2. Jan 2012, at 22:16 , sthaug@nethelp.no wrote: >>>> Does such traffic actually occur in the wild, or would it only be used >>>> in attacks? >>> >>> Such traffic absolutely occurs in the wild. I have three reasonably >>> busy name servers where this is logged as an error from the ipfw code, >>> e.g. >> >> and I know of a couple of more people who have seen it and have ways to >> trigger it with legitimate servers. I have never tracked things down >> in more detail at some point back. > > If anybody would like to track down this, I can supply pcap data. You'd need to go to the origins most likely and get into touch with them, ask them, work with them to identify things and see if you can find a common denominator... It might really be worth doing so; in case we are hunting misconfigurations or bugs here and discussing the merits on how to handle other than drop;-) /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From dwing@cisco.com Mon Jan 2 15:02:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83A421F8467 for ; Mon, 2 Jan 2012 15:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3P6M5E2pmuJ for ; Mon, 2 Jan 2012 15:02:39 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1062721F8449 for ; Mon, 2 Jan 2012 15:02:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4511; q=dns/txt; s=iport; t=1325545359; x=1326754959; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=OSaWOwd4qR1qbgBu0tRa+VpFPz2MxReMLnhzxJSmkmY=; b=Rl2GJAGYgmxDQ6zTTNeyDFzy3HRQV2uqc3CxUtaUNAsv6yA2MZKijbnK eWdQSkuo/BWr5EF87mt1R91Z8iu2FEKt1RxLjrsl3NgBbvcbtIoIUToqt yCT1xJeznfTDCHaldijGjk/FKJvvmPKoDj53MXlQ/TW1vG9CIWF7H+97W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4DAE03Ak+rRDoI/2dsb2JhbABDggWaF4FqjlSBBYFyAQEBAwEBAQEFCgEVAhA0CwUHAQMCCQ8CBAEBAScHGQ4VCgkIAQEEARILF4dYCJZvAZ08jA8EiDeEeQGaJg X-IronPort-AV: E=Sophos;i="4.71,446,1320624000"; d="scan'208";a="23401222" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 02 Jan 2012 23:02:39 +0000 Received: from dwingWS ([10.21.78.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q02N2cHX022853; Mon, 2 Jan 2012 23:02:38 GMT From: "Dan Wing" To: "'Fernando Gont'" , "'Brian E Carpenter'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> In-Reply-To: <4EF7D880.3090102@gont.com.ar> Subject: RE: Fragmentation-related security issues Date: Mon, 2 Jan 2012 15:02:38 -0800 Message-ID: <002f01ccc9a2$9fab9990$df02ccb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczDqn8IMzS+vk8jTISIHLLix/l35QF911fg Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:02:39 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Fernando Gont > Sent: Sunday, December 25, 2011 6:14 PM > To: Brian E Carpenter > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > Hi, Brian, > > On 12/24/2011 05:06 PM, Brian E Carpenter wrote: > >>>> That aside, I don't know whether e.g. NAT64 or the like used this > >>>> (.e.g, whether they are used for transition technologies as > envisioned > >>>> in RFC 2460). However, it might also be the case that such "atomic > >>>> fragments" are generated when communicating through networks that > do > >>>> not really have a MTU >= 1280. In such scenarios there might be > some > >>>> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop > MTU > >>>> smaller than 1280, thus resulting in atomic fragments (such that > it's > >>>> easier for the "gateway" to fragment the IPv6 packets). > >>> Yes, this seems a plausible explanation. I wouldn't consider this > >>> actual use, rather network misconfiguration. > >> > >> Why? > > > > MTU <1280 is a complete breach of the IPv6 standard, so it is by > > definition a misconfiguration. > > Well, as long as communication does work without requiring the sending > node to fragment packets to < 1280, the standard is not being "broken". > > In the scenario I was describing, the underlying reason for receiving > an > ICMPv6 PTB <1280 might be a network that doesn't support an MTU >= 1280 > (and hence, that violates the standard). It is not a violation to send PTB of less then 1280. Never has been, even going back to RFC1883 when the IPv6 minimum MTU was 576, http://tools.ietf.org/html/rfc1883#section-5 says: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 576. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 576, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 528 octets (576 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. Note: Path MTU Discovery must be performed even in cases where a host "thinks" a destination is attached to the same link as itself. and the current IPv6 specification also allows PTB < 1280, http://tools.ietf.org/html/rfc2460#section-5 says: In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 1280, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments. Note that this means the payload may have to be reduced to 1232 octets (1280 minus 40 for the IPv6 header and 8 for the Fragment header), and smaller still if additional extension headers are used. > However, that's irrelevant as > long as the sending host is not required to fragment to <1280 for > communication to work. > > That aside, from my perspecitive std violation != misconfiguration. A > misconfiguration is probably the result of an error (probably on the > side of the administrator), while an std violation such as the one that > we're possibly talking about is most likely the result of a deliverate > action (which is probably not going to be fixed even if it's reported). -d > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dwing@cisco.com Mon Jan 2 15:09:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3CE11E8073 for ; Mon, 2 Jan 2012 15:09:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6zv716-tx7q for ; Mon, 2 Jan 2012 15:09:33 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9AB21F8A91 for ; Mon, 2 Jan 2012 15:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5657; q=dns/txt; s=iport; t=1325545773; x=1326755373; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=SVgm/uqrdEROpNW01W8+C7RyOWisD/2uyB+KGTibIt4=; b=J9MbR7w5Sn9nfHrWBaGDr8shMQCqRI3SnZgtI8yYIIObNzR2Faphw7Rc VHkyYqk821dN+gxul+8L4QUYw+8qiIZiqG9PfNslyor1sVjxpijrnXRc1 xiXuz23RC3UzxZxyEl06n7QTBRPv03CLWdWBfeu+N/q12joY929KBzbqa U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUgAE44Ak+rRDoI/2dsb2JhbAApGoIFnAGLRIMQgQWBcgEBAQMBAQEBBQoBFQIQNAsFBwEDAgkPAgQBAQEnBxkOFQoJCAEBBAESCxeHWAgjlksBnTyMDwSIN4R5AZomSw X-IronPort-AV: E=Sophos;i="4.71,446,1320624000"; d="scan'208";a="23357490" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Jan 2012 23:09:32 +0000 Received: from dwingWS ([10.21.78.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q02N9WQb027685; Mon, 2 Jan 2012 23:09:32 GMT From: "Dan Wing" To: "'Bjoern A. Zeeb'" , References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> In-Reply-To: Subject: RE: Fragmentation-related security issues Date: Mon, 2 Jan 2012 15:09:32 -0800 Message-ID: <003001ccc9a3$9631cc80$c2956580$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczJm3SVKF53c1+aRMWF3qBuJV+4YAAB4etg Content-Language: en-us Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:09:34 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Bjoern A. Zeeb > Sent: Monday, January 02, 2012 2:11 PM > To: sthaug@nethelp.no > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > On 20. Dec 2011, at 11:44 , sthaug@nethelp.no wrote: > > Hey, > > I guess I should follow-up on this one. > > >>> IPv6 allows packets to contain a Fragment Header, without the > packet > >>> being actually fragmented into multiple pieces. Such packets > >>> typically result from hosts that have received an ICMPv6 "Packet > Too > >>> Big" error message that advertises a "Next-Hop MTU" smaller than > 1280 > >>> bytes, and are currently processed by hosts as "fragmented > >>> traffic". > >> > >> Does such traffic actually occur in the wild, or would it only be > used > >> in attacks? > > > > Such traffic absolutely occurs in the wild. I have three reasonably > > busy name servers where this is logged as an error from the ipfw > code, > > e.g. > > and I know of a couple of more people who have seen it and have ways to > trigger it with legitimate servers. I have never tracked things down > in more detail at some point back. > > > > Dec 16 14:04:04 slem kernel: IPFW2: IPV6 - Invalid Fragment Header > > ... > > This is because these name servers haven't (yet) been upgraded to a > > FreeBSD version where bug report kern/145733 haven't been fixed. It > > *is* fixed in newer FreeBSD versions, e.g. 8.2-STABLE. > > And given I am responsible for both committing the original "block" and > the relaxed version let me elaborate a bit on this: > > Contrary to how a lot of people seem to read RFC 2460, especially the > last > paragraph of section 5 (also subject to Florian's Errata 2843), Errata 2843, http://www.rfc-editor.org/errata_search.php?eid=2843, will break stateless IPv6/IPv4 translation, which was originally defined in RFC2765 and superseded by RFC6145 (published April 2011). > I basically read (in) the past: > > 4.5 "The Fragment header is used by an IPv6 source to send a packet > larger > than would fit in the path MTU to its destination." > > ``You shall not add a fragment header unless you really need to''. > > The only way you must add a fragment header for a packet size below > 1280 is > when it is a packet going to a v4 destination (i.e. say through NAT64 > these > days). How you can track this (if you can) and how you get that > information > is beyond the scope of 2460 but you need to know to be able to. > Otherwise > you shall not. > > This is the reason ipfw originally dropped what people now seem to call > "atomic fragments". > > When I PR started to look at the PR I consulted briefly with Bob and > the > outcome of the short exchange for me was: > > - the "atomic frags" do not seem to hurt in this particular filtering > case > and could possibly be allowed. > - I prepared an errata text suggesting that the text in 4.5 was > clarified > allowing "atomic frags" but discouraging their usage, especially > given > aforementioned errata threatens to remove the paragraph from section > 5, > which is the only real reason people seem to think they are valid. > > > While I still feel that these "atomic frags" should be sent to the > packet > shredder on first sight it seemed to match reality (and especially > operational impact) better. However I left a sysctl for individuals to > control their preference. > > > Another thing on the "atomic frags" I was (partly) shown was that they > seemed > to have a length in the 50 octets size which would even be way below > other > minimums. So I am really not feeling too confident that it's not just > silly > stacks or software bugs and it would really be thrilling if people > could figure > out OS and version and reason why some systems send them. > > > On the entire "fragmentation related security issues" topic, I feel we > are > seriously heading into wrong directions to just more complications > rather than > simplifications. > > The idea of having the fragment offset to stay compatible the way > things worked > in IPv4 certainly was a great idea and has later proven to be a PITA. Agreed, it's a PITA. Fragmentation is a PITA, though, not just this one aspect of it. > What I'd > really like to have is a silly fragment counter 1..n, so no overlapping > possible > (and not just not allowed on paper anymore as that does not remove that > code > to check from the stacks), simple handling of duplicate fragments, and > no > "atomic frags" allowed. > Luckily the fragment header still has a lot of spare space that could > allow > to indicate which scheme is used and dropping a packet unless a bit is > set > (not being set indicating the old scheme) is really easy to implement, > esp. > after a transition period and ripping the old code out would be as well > then;-) > I 'd really not want to add even more complicated house keeping and > stuff > long term. We're sortof in the middle of the IPv6/IPv4 transition now, though.. -d > /bz > > -- > Bjoern A. Zeeb You have to have > visions! > It does not matter how good you are. It matters what good you do! > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Mon Jan 2 15:23:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9A21F0C4D for ; Mon, 2 Jan 2012 15:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seXgW1wzP3Z9 for ; Mon, 2 Jan 2012 15:23:45 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id DA0A81F0C35 for ; Mon, 2 Jan 2012 15:23:44 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RhrE6-0007nB-JS; Tue, 03 Jan 2012 00:23:35 +0100 Message-ID: <4F023C6B.4040401@si6networks.com> Date: Mon, 02 Jan 2012 20:23:23 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Dan Wing Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> In-Reply-To: <002f01ccc9a2$9fab9990$df02ccb0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:23:45 -0000 On 01/02/2012 08:02 PM, Dan Wing wrote: >> Well, as long as communication does work without requiring the sending >> node to fragment packets to < 1280, the standard is not being "broken". >> >> In the scenario I was describing, the underlying reason for receiving >> an >> ICMPv6 PTB <1280 might be a network that doesn't support an MTU >= 1280 >> (and hence, that violates the standard). > > It is not a violation to send PTB of less then 1280. Never has been, > even going back to RFC1883 when the IPv6 minimum MTU was 576, > http://tools.ietf.org/html/rfc1883#section-5 says: The violation would be that of not support an MTU >= 1280, rather than the sending of the ICMPv6 PTB. > and the current IPv6 specification also allows PTB < 1280, > http://tools.ietf.org/html/rfc2460#section-5 says: > > In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node > is not required to reduce the size of subsequent packets to less than > 1280, but must include a Fragment header in those packets so that the > IPv6-to-IPv4 translating router can obtain a suitable Identification > value to use in resulting IPv4 fragments. Note that this means the > payload may have to be reduced to 1232 octets (1280 minus 40 for the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used. Exactly. And my question was about whether the "atomic fragments" that were found in the wild were the result of translators, or of IPv6 networks that "violate" the standard and do not support an MTU of >= 1280. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Jan 2 15:27:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E611E80C8 for ; Mon, 2 Jan 2012 15:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yb8RSJSED5TB for ; Mon, 2 Jan 2012 15:27:02 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id AD80E11E8073 for ; Mon, 2 Jan 2012 15:27:02 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RhrHO-0007oQ-3v; Tue, 03 Jan 2012 00:26:58 +0100 Message-ID: <4F023D3D.60900@si6networks.com> Date: Mon, 02 Jan 2012 20:26:53 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> In-Reply-To: <20120102.231616.74700645.sthaug@nethelp.no> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bzeeb-lists@lists.zabbadoz.net, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:27:03 -0000 On 01/02/2012 07:16 PM, sthaug@nethelp.no wrote: >> >> and I know of a couple of more people who have seen it and have ways to >> trigger it with legitimate servers. I have never tracked things down >> in more detail at some point back. > > If anybody would like to track down this, I can supply pcap data. I'd be interested. Please tar, gz and send to fgont@si6networks.com (or provide an URL). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Mon Jan 2 16:21:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0321F8452 for ; Mon, 2 Jan 2012 16:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uTsT4-wdrLT for ; Mon, 2 Jan 2012 16:21:51 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 22E9921F8453 for ; Mon, 2 Jan 2012 16:21:51 -0800 (PST) Received: by qadb15 with SMTP id b15so9309607qad.10 for ; Mon, 02 Jan 2012 16:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=zDruk28TVtipabHOGM3LD7TX7+2psUWh6XskxXZuNh0=; b=soIKLEJux4XTuBlyAwa0/EbflVyFGwtAxUNPyIns21MDXdoHMO0G3zCPxHdfgXIe0i 7DPcdebcBtUqt81wP6qudjx0aCbGn2d7hm3hhNEi26QTGP9kb7uSQhKoanXG8VeEzLKq dAyDO8+Z+NqbWyKmQtfusQhI6jfuk7ko5Z1a8= Received: by 10.224.33.15 with SMTP id f15mr42948132qad.38.1325550107618; Mon, 02 Jan 2012 16:21:47 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id r10sm96217311qaz.7.2012.01.02.16.21.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 16:21:46 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: Fragmentation-related security issues Date: Mon, 2 Jan 2012 19:21:45 -0500 Message-Id: <12DB93EA-19FA-425C-B8DB-8CD609F83A6B@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 00:21:51 -0000 Earlier, Fernando Gont wrote, in part: > ... my question was about whether the "atomic fragments" > that were found in the wild were the result of translators, > or of IPv6 networks that "violate" the standard and > do not support an MTU of >=3D 1280. I have been told of real-world IPv6 deployments where the link MTU is smaller than 1280,=20 while the limited link bandwidth makes adding a new=20 segmentation protocol layer impractical. I believe=20 these account for some of the 576 byte or 512 byte advertised Link MTU sizes in IPv6 PMTU "Too Big"=20 messages that are seen in the real world. I also know of real-world IPv6 deployments with translators. I expect translators to become=20 much more common soon. As far as I am aware, neither of the above would produce PMTU "Too Big" messages with an advertised link MTU very much under 500 bytes. =20 IMHO, the 1280 byte number is far too big for a minimum IPv6 MTU. I've held the view that much=20 above 512 bytes is problematic on RF links for=20 MANY years now, as the Minutes from long ago illustrate (search for "MTU"): = = Ran From minhong.wu@gmail.com Mon Jan 2 19:28:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7129621F8585 for ; Mon, 2 Jan 2012 19:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8yGKBrqT8LU for ; Mon, 2 Jan 2012 19:28:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C46D021F8584 for ; Mon, 2 Jan 2012 19:28:34 -0800 (PST) Received: by iabz21 with SMTP id z21so8881439iab.31 for ; Mon, 02 Jan 2012 19:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oalVKbyogYbzbanB102PQY55Cq9wK/8RlI1b6IZ9LHk=; b=nTXMtsts+49qWZe0ae5JxoJzz3enoIxflVoJhiFgrtKcju0zpDJ34ruWNhi3nqZVRH aAMt7v1JWRFTYSkWksMOHp97wR4NcoPpEoiVP6iT3LfXOcJeZBKZXsLPsRd0ISdpF8Aj vh/QaCMO0FpQW+jrRsGNg/PQEDDAnAdQ7Vld8= MIME-Version: 1.0 Received: by 10.50.159.131 with SMTP id xc3mr59965388igb.27.1325561313423; Mon, 02 Jan 2012 19:28:33 -0800 (PST) Received: by 10.50.208.103 with HTTP; Mon, 2 Jan 2012 19:28:33 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Jan 2012 11:28:33 +0800 Message-ID: Subject: Re: Prefix Delegation questions From: Ming-Hong Wu To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=14dae9399dcd36f2a304b5974be2 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 03:28:35 -0000 --14dae9399dcd36f2a304b5974be2 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I know Prefix Delegation. I want to know if there is any RFC / specification said that what protocols should support PD. Let's say we have a router supporting 1 WAN and 1 LAN. Suppose the WAN acquires an prefix (with 64 length) and forms its WAN IP. LAN-side users still can't access IPv6 Internet, right ? As I know, the router must request for another prefix (e.g. 2001:1234:5678::/48) and assign a suitable prefix (e.g. 2001:1234:5678:ABCD::/64) to its LAN, by using Radvd to advertise this prefix. Then, the LAN-side users can access IPv6 Internet. If above assumption is wrong, please correct me. Otherwise, I want to make sure, what available methods can the router use to request the prefix, 2001:1234:5678::/48 ? DHCPv6 is the only solution ? Any other ? Sincerely --14dae9399dcd36f2a304b5974be2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

=A0 =A0 I know Pr= efix Delegation. I want to know if there is any RFC / specification said th= at what protocols should support PD.

= =A0 =A0 Let's say we have a router supporting 1 WAN and 1 LAN. Suppose = the WAN acquires an prefix (with 64 length) and forms
its WAN IP. LAN-side users still can't access IPv6 Internet,= right ?

=A0 =A0 As I know, the router= must request for another prefix (e.g. 2001:1234:5678::/48) and assign a su= itable prefix (e.g. 2001:1234:5678:ABCD::/64)
to its LAN, by using Radvd to advertise this prefix. Then, the L= AN-side users can access IPv6 Internet.


=A0 =A0 If above assumption is wrong, please correct= me. Otherwise, I want to make sure, what available methods
can the router use to request the prefix, 2001:1234:5678::/48 ? = DHCPv6 is the only solution ? Any other ?


Sincerely
--14dae9399dcd36f2a304b5974be2-- From ichiroumakino@gmail.com Tue Jan 3 00:07:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E6921F84AB for ; Tue, 3 Jan 2012 00:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsNXf5gPid1T for ; Tue, 3 Jan 2012 00:07:14 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8BE921F842E for ; Tue, 3 Jan 2012 00:07:13 -0800 (PST) Received: by werb14 with SMTP id b14so9132923wer.31 for ; Tue, 03 Jan 2012 00:07:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ytXAC9s/Ts+EHW5Bt15ERJAvwh0Bus3wp7m3R8w+71g=; b=h0Z7cA1jlaKOOH569FNyZal9a0Z+jRLEE0Z6iblHQvKFbto2zl5mETLoNnUMl/4dBW G70nem6P6XnF3LuySYxCgVqHRbhabzjlxtVIBHSQ6zAQ1X5b6V8SsvnrKSjvvAQG2JdB YhwikOLG74Syi47Q6mTNapYd5wdOZZbMPfEwY= Received: by 10.216.138.38 with SMTP id z38mr34729562wei.14.1325578033042; Tue, 03 Jan 2012 00:07:13 -0800 (PST) Received: from [10.147.13.4] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fq7sm53657124wbb.1.2012.01.03.00.07.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 00:07:11 -0800 (PST) Sender: Ole Troan Subject: Re: Prefix Delegation questions Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ole Troan In-Reply-To: Date: Tue, 3 Jan 2012 09:07:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <16389D46-2D57-4999-A017-93D4B1DCA17B@employees.org> References: To: Ming-Hong Wu X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:07:15 -0000 > I know Prefix Delegation. I want to know if there is any RFC / = specification said that what protocols should support PD. RFC3633 / RFC6204. RFC3633 _is_ a protocol. I don't understand what you mean by "what = protocols should support PD". > Let's say we have a router supporting 1 WAN and 1 LAN. Suppose the = WAN acquires an prefix (with 64 length) and forms > its WAN IP. LAN-side users still can't access IPv6 Internet, right ? PD delegates a prefix to the LAN-side links, not the WAN side. for the = WAN side normal address assignment is used (SLAAC, DHCP). > As I know, the router must request for another prefix (e.g. = 2001:1234:5678::/48) and assign a suitable prefix (e.g. = 2001:1234:5678:ABCD::/64) > to its LAN, by using Radvd to advertise this prefix. Then, the = LAN-side users can access IPv6 Internet. >=20 >=20 > If above assumption is wrong, please correct me. Otherwise, I want = to make sure, what available methods > can the router use to request the prefix, 2001:1234:5678::/48 ? DHCPv6 = is the only solution ? Any other ? yes, your assumption is wrong. corrected. DHCPv6 (RFC3633) is the only IETF specified protocol mechanism for = prefix delegation. you can possibly do it with TR-69, DOCSIS or manual configuration. cheers, Ole= From fweimer@bfk.de Tue Jan 3 00:42:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870D221F846E for ; Tue, 3 Jan 2012 00:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqmx5np63BnE for ; Tue, 3 Jan 2012 00:42:11 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3AC21F8517 for ; Tue, 3 Jan 2012 00:42:04 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RhzwY-0002Gq-E2; Tue, 03 Jan 2012 08:42:02 +0000 Received: by bfk.de with local id 1RhzwY-0007rE-8H; Tue, 03 Jan 2012 08:42:02 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> Date: Tue, 03 Jan 2012 08:42:02 +0000 In-Reply-To: <4EF5647B.6070903@si6networks.com> (Fernando Gont's message of "Sat, 24 Dec 2011 02:34:51 -0300") Message-ID: <82sjjxqisl.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:42:12 -0000 * Fernando Gont: > Hi, Florian, > > On 12/23/2011 07:46 AM, Florian Weimer wrote: >>> That aside, I don't know whether e.g. NAT64 or the like used this >>> (.e.g, whether they are used for transition technologies as envisioned >>> in RFC 2460). However, it might also be the case that such "atomic >>> fragments" are generated when communicating through networks that do >>> not really have a MTU >=3D 1280. In such scenarios there might be some >>> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU >>> smaller than 1280, thus resulting in atomic fragments (such that it's >>> easier for the "gateway" to fragment the IPv6 packets). >>=20 >> Yes, this seems a plausible explanation. I wouldn't consider this >> actual use, rather network misconfiguration.=20=20 > > Why? What Brian said---IPv6 is supposed to have a lower bound on the MTU. I just don't think it's a good idea to through that out of the window because there are genuine advantages. >> In my opinion, we need >> more evidence that these fragments actually serve a useful purpose. >>=20 >>> That aside, there's the proposal by Mark Andrews which would add yet >>> another use case for these atomic fragments. >>=20 >> Not really. It's a workaround so that stateless IPv6 services are >> possible, despite this protocol weiredness. > > Not sure what you mean. Without the API change in draft-andrews-6man-force-fragmentation, it is flat out impossible to server IPv6 traffic in a stateless fashion. The stack is required to keep a per-destination cache which records the necessity of a fragment extension header, even if the application never sends any packets larger than 1280 bytes. > Sorry, I cannot see why some packets would require going through a > translator, while others wouldn't. The joy of packet switching. 8-) > That is, if the intended destination is really a v4 node, all packets > meant to it will go through a translator, If it's not, none will. If the target is a v4 node, surely the network can just fragment as needed, and reassemble using the v4 fragmentation information? That's why I assumed the actual use case has to be more complicated (such as translation back to v6). I'm attempting a reductio ad absurdum here---trying to show that for all potential use cases of atomic fragments, there are much simpler alternatives, and the remaining ones are utterly bizarre and not worth supporting. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From minhong.wu@gmail.com Tue Jan 3 00:50:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC99F21F85A2 for ; Tue, 3 Jan 2012 00:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFaMmtMgrSUV for ; Tue, 3 Jan 2012 00:50:18 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19EB921F859F for ; Tue, 3 Jan 2012 00:50:18 -0800 (PST) Received: by iabz21 with SMTP id z21so9310412iab.31 for ; Tue, 03 Jan 2012 00:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QcHho5uAjAC45PaBIUwmTkvs6HBj9yzG/LIZ0ueAm4c=; b=NZRRwLswGZLtfp2DIprE4F21lEySX40okxmVdI3OQ7yxGq8vHNmQwH4Wt2Dwv+pJy9 D4K6yabL0y8jcGfL3/Lp+aOO51qDkFU5BnqfAgda0EQ1pZ9oX2a/HiGNldA9u2zXygfg wQY38xVtXeRncsxG9HyPKJbB8qSSNI4ZQsbP0= MIME-Version: 1.0 Received: by 10.42.151.68 with SMTP id d4mr54243502icw.36.1325580617703; Tue, 03 Jan 2012 00:50:17 -0800 (PST) Received: by 10.50.208.103 with HTTP; Tue, 3 Jan 2012 00:50:17 -0800 (PST) In-Reply-To: <16389D46-2D57-4999-A017-93D4B1DCA17B@employees.org> References: <16389D46-2D57-4999-A017-93D4B1DCA17B@employees.org> Date: Tue, 3 Jan 2012 16:50:17 +0800 Message-ID: Subject: Re: Prefix Delegation questions From: Ming-Hong Wu To: Ole Troan Content-Type: multipart/alternative; boundary=90e6ba6e872ed6e0a104b59bc9d4 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 08:50:19 -0000 --90e6ba6e872ed6e0a104b59bc9d4 Content-Type: text/plain; charset=ISO-8859-1 First, thanks! By "what protocols should support PD", I mean, PD sounds like a mechanism: to delegate a prefix. Like RFC 3769, I can't make sure how it is achieved. As you said, RFC 3633 is a protocol, like an extension of DHCPv6 that can do PD. Thanks again for your reply and the answer of DHCPv6 is exactly what I want to confirm :-) I'm just curious that except DHCPv6, if there is existing any other protocol for PD implementation. 2012/1/3 Ole Troan > > I know Prefix Delegation. I want to know if there is any RFC / > specification said that what protocols should support PD. > > RFC3633 / RFC6204. > RFC3633 _is_ a protocol. I don't understand what you mean by "what > protocols should support PD". > > > Let's say we have a router supporting 1 WAN and 1 LAN. Suppose the > WAN acquires an prefix (with 64 length) and forms > > its WAN IP. LAN-side users still can't access IPv6 Internet, right ? > > PD delegates a prefix to the LAN-side links, not the WAN side. for the WAN > side normal address assignment is used (SLAAC, DHCP). > > > As I know, the router must request for another prefix (e.g. > 2001:1234:5678::/48) and assign a suitable prefix (e.g. > 2001:1234:5678:ABCD::/64) > > to its LAN, by using Radvd to advertise this prefix. Then, the LAN-side > users can access IPv6 Internet. > > > > > > If above assumption is wrong, please correct me. Otherwise, I want > to make sure, what available methods > > can the router use to request the prefix, 2001:1234:5678::/48 ? DHCPv6 > is the only solution ? Any other ? > > yes, your assumption is wrong. corrected. > > DHCPv6 (RFC3633) is the only IETF specified protocol mechanism for prefix > delegation. > you can possibly do it with TR-69, DOCSIS or manual configuration. > > cheers, > Ole -- Sincerely, minhong --90e6ba6e872ed6e0a104b59bc9d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First, thanks!

By "what protocols should support PD= ", I mean, PD sounds like a mechanism: to delegate a prefix.
Like RFC 3769, I can't make sure how it is achieved.

As you said, RFC 3633 is a protocol, like an extension of DHCPv6= that can do PD.

Thanks again for your reply and t= he answer of DHCPv6 is exactly what I want to confirm :-)
I'm= just curious that except DHCPv6, if there is existing any other protocol f= or PD implementation.
=A0

2012/1/3 Ole Troan <otroan@employees.or= g>
> =A0 =A0 I know Prefix Delegation. I want to know if = there is any RFC / specification said that what protocols should support PD= .

RFC3633 / RFC6204.
RFC3633 _is_ a protocol. I don't understand what you mean by "what= protocols should support PD".

> =A0 =A0 Let's say we have a router supporting 1 WAN and 1 LAN. Sup= pose the WAN acquires an prefix (with 64 length) and forms
> its WAN IP. LAN-side users still can't access IPv6 Internet, right= ?

PD delegates a prefix to the LAN-side links, not the WAN side. for th= e WAN side normal address assignment is used (SLAAC, DHCP).

> =A0 =A0 As I know, the router must request for another prefix (e.g. 20= 01:1234:5678::/48) and assign a suitable prefix (e.g. 2001:1234:5678:ABCD::= /64)
> to its LAN, by using Radvd to advertise this prefix. Then, the LAN-sid= e users can access IPv6 Internet.
>
>
> =A0 =A0 If above assumption is wrong, please correct me. Otherwise, I = want to make sure, what available methods
> can the router use to request the prefix, 2001:1234:5678::/48 ? DHCPv6= is the only solution ? Any other ?

yes, your assumption is wrong. corrected.

DHCPv6 (RFC3633) is the only IETF specified protocol mechanism for prefix d= elegation.
you can possibly do it with TR-69, DOCSIS or manual configuration.

cheers,
Ole



--
Sincerely= ,
minhong

--90e6ba6e872ed6e0a104b59bc9d4-- From pch-b29AA871B@u-1.phicoh.com Tue Jan 3 01:32:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5156321F84BB for ; Tue, 3 Jan 2012 01:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7EfcI0bH8SE for ; Tue, 3 Jan 2012 01:32:03 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC8D21F84B3 for ; Tue, 3 Jan 2012 01:32:03 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Ri0in-0001ZgC; Tue, 3 Jan 2012 10:31:53 +0100 Message-Id: To: RJ Atkinson Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com In-reply-to: Your message of "Mon, 2 Jan 2012 19:21:45 -0500 ." <12DB93EA-19FA-425C-B8DB-8CD609F83A6B@gmail.com> Date: Tue, 03 Jan 2012 10:31:47 +0100 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:32:04 -0000 In your letter dated Mon, 2 Jan 2012 19:21:45 -0500 you wrote: >I have been told of real-world IPv6 deployments >where the link MTU is smaller than 1280, >while the limited link bandwidth makes adding a new >segmentation protocol layer impractical. I believe >these account for some of the 576 byte or 512 byte >advertised Link MTU sizes in IPv6 PMTU "Too Big" >messages that are seen in the real world. So if you run TCP over such a link then you an get extra overhead of more than 60 octets (IPv6 header + TCP header) compared to a link with an MTU of 1280. For UDP the amount is about the same (IPv6, fragment header, UDP header). And you are saying that that sort of overhead doesn't warrant finding an unused bit somewhere to signal an adaptation layer? From sthaug@nethelp.no Tue Jan 3 01:55:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E1921F8584 for ; Tue, 3 Jan 2012 01:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUIATa4WvPhC for ; Tue, 3 Jan 2012 01:55:28 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 294D521F8581 for ; Tue, 3 Jan 2012 01:55:27 -0800 (PST) Received: (qmail 44979 invoked from network); 3 Jan 2012 09:55:26 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 3 Jan 2012 09:55:26 -0000 Date: Tue, 03 Jan 2012 10:55:26 +0100 (CET) Message-Id: <20120103.105526.112588594.sthaug@nethelp.no> To: bzeeb-lists@lists.zabbadoz.net Subject: Re: Fragmentation-related security issues From: sthaug@nethelp.no In-Reply-To: References: <20120102.231616.74700645.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 09:55:29 -0000 > >> and I know of a couple of more people who have seen it and have ways to > >> trigger it with legitimate servers. I have never tracked things down > >> in more detail at some point back. > > > > If anybody would like to track down this, I can supply pcap data. > > You'd need to go to the origins most likely and get into touch with them, > ask them, work with them to identify things and see if you can find a > common denominator... Pcap files have now been supplied to two persons who expressed interest in following up on this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From rja.lists@gmail.com Tue Jan 3 04:32:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971F021F84B4 for ; Tue, 3 Jan 2012 04:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbI-Rxvikvln for ; Tue, 3 Jan 2012 04:32:19 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0524321F848B for ; Tue, 3 Jan 2012 04:32:18 -0800 (PST) Received: by qcsf15 with SMTP id f15so11656877qcs.31 for ; Tue, 03 Jan 2012 04:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=gLK0xx1s9XB26rRkxpAfP7uH1qHYjBW3T2aMn9QtKG0=; b=UZFmFq4H8W/Jq4loeMNtL46idfTmt9D4iLzaxloLCDOEj4VnL3ZZaZ7gKjHBAmvM6B 0vp03vdcrraXSKK/5Pjftkp4EUZ+3mqN/ALx3LJgm27A/P24BP3bdHGblwKhCiUWXZZ6 Demsu82eBHJPyc6eX+ivIWqMq7AiENBAGgn/A= Received: by 10.224.31.202 with SMTP id z10mr60714419qac.96.1325593937530; Tue, 03 Jan 2012 04:32:17 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id dj9sm99694725qab.18.2012.01.03.04.32.16 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 04:32:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Fragmentation-related security issues From: RJ Atkinson In-Reply-To: Date: Tue, 3 Jan 2012 07:32:17 -0500 Content-Transfer-Encoding: 7bit Message-Id: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> References: To: ipv6@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 12:32:19 -0000 On 03 Jan 2012, at 04:31 , Philip Homburg wrote: > In your letter dated Mon, 2 Jan 2012 19:21:45 -0500 you wrote: >> I have been told of real-world IPv6 deployments >> where the link MTU is smaller than 1280, >> while the limited link bandwidth makes adding a new >> segmentation protocol layer impractical. I believe >> these account for some of the 576 byte or 512 byte >> advertised Link MTU sizes in IPv6 PMTU "Too Big" >> messages that are seen in the real world. > > So if you run TCP over such a link then you an get > extra overhead of more than 60 octets (IPv6 header + TCP header) > compared to a link with an MTU of 1280. For UDP > the amount is about the same (IPv6, fragment header, UDP header). > > And you are saying that that sort of overhead > doesn't warrant finding an unused bit somewhere > to signal an adaptation layer? Of course an adaptation layer has various costs beyond a single bit, but please also consider the case where there are no unused bits at hand. I'm saying the folks responsible for such links tell me they have looked into it in detail, tell me they looked at the whole problem including all of the system impacts and costs, and tell me that they concluded that it was MUCH better to continue to use IPv6 without adaptation layer overhead. Reports say their current approach is operationally very workable (i.e. with the IPv6 Fragment Header) and that multiple vendors' products work well in their deployment. I'll note that RFC-1883, Section 5 specified a minimum IPv6 Link MTU of 576 octets. If that number had not later been changed, then we would not be having this discussion. The choice of minimum IPv6 Link MTU is necessarily somewhat arbitrary. Different numbers are optimal for different deployments. It is merely sad that the IETF chose such a large number. The other approach I've heard about being taken for working over small MTU links is simply to perform (one-way) IPv6->IPv4 protocol translation, since IPv4 works natively on links that small. It seems sad that the IETF decision is pushing people towards a protocol translation approach. I can't blame the operations folks responsible for such deployments; they are simply trying to move their bits reliably and cost-effectively. Yours, Ran From bs7652@att.com Tue Jan 3 06:13:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41D821F84DF for ; Tue, 3 Jan 2012 06:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.439 X-Spam-Level: X-Spam-Status: No, score=-104.439 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+xES+iXh7NE for ; Tue, 3 Jan 2012 06:13:49 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 38D7221F84DE for ; Tue, 3 Jan 2012 06:13:49 -0800 (PST) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1325600027!8625760!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11637 invoked from network); 3 Jan 2012 14:13:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Jan 2012 14:13:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q03ECHIN029194; Tue, 3 Jan 2012 09:12:18 -0500 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q03ECARP029042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2012 09:12:12 -0500 Received: from 01AL10015010627.AD.BLS.COM (01AL10015010627.ad.bls.com [90.152.44.196]) by sflint04.pst.cso.att.com (RSA Interceptor); Tue, 3 Jan 2012 09:13:31 -0500 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01AL10015010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 08:12:38 -0600 Received: from 01NC27689010650.AD.BLS.COM ([90.144.44.120]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 09:12:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {A0FBF337-DD42-4443-9E8D-F46630C5A515} MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCCA21.BEC23E0C" x-cr-hashedpuzzle: EGMx GMQX HOMq KetZ SIX9 UFcP VGoy aL6i fbZ2 gyB9 hSh8 kf14 mj5p oTn4 r1Mx r+VS; 4; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBkAG8AdQBnAGIAQABkAG8AdQBnAGIAYQByAHQAbwBuAC4AdQBzADsAaQBwAHYANgBAAGkAZQB0AGYALgBvAHIAZwA7AHIAbwBnAGUAcgBqAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {A0FBF337-DD42-4443-9E8D-F46630C5A515}; YgBzADcANgA1ADIAQABhAHQAdAAuAGMAbwBtAA==; Tue, 03 Jan 2012 14:13:20 GMT; UgBFADoAIABJAFAAdgA2ACAAUgBvAHUAdABlAHIAIABBAGQAdgBlAHIAdABpAHMAZQBtAGUAbgB0ACAATwBwAHQAaQBvAG4AIABmAG8AcgAgAEYAbwBvAGIAYQByACAAQwBvAG4AZgBpAGcAdQByAGEAdABpAG8AbgA= Content-class: urn:content-classes:message Subject: RE: IPv6 Router Advertisement Option for Foobar Configuration Date: Tue, 3 Jan 2012 09:13:20 -0500 Message-ID: <750BF7861EBBE048B3E648B4BB6E8F4F21AF8700@crexc50p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Router Advertisement Option for Foobar Configuration Thread-Index: AczDDkxZAywksmg3TSe18cX54zjm5gCmmd+g References: <7C362EEF9C7896468B36C9B79200D8350D026F16A8@INBANSXCHMBSA1.in.alcatel-lucent.com><4EF22786.2070908@dougbarton.us> <4EF2373B.6060905@gmail.com><4EF24007.3030300@dougbarton.us> <4EF258A5.1040106@gmail.com><4EF4344B.6040504@dougbarton.us> From: "STARK, BARBARA H" To: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "Doug Barton" X-OriginalArrivalTime: 03 Jan 2012 14:12:37.0723 (UTC) FILETIME=[BF300AB0:01CCCA21] X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: 6man Mailing List , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 14:13:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCCA21.BEC23E0C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm very much opposed to extending RA for this purpose. Having 2 ways to = do the same thing serves to increase complexity of the overall = ecosystem. Unless you can guarantee that the 2nd method will only ever = be used in a closed system (network manager consciously knows that this = is the mechanism all installed devices support and will use, so that = interoperability is guaranteed). If you cannot guarantee that it will = only exist in a closed system and that no user will ever be confused, = then by introducing a 2nd method, you are increasing complexity (more = than doubling it, for this function) for the majority of devices (that = will have to implement both to be assured of interoperability, and will = have to implement "tie-breaker" functionality as well). Doubled = complexity for the majority in order to achieve increased simplicity for = a minority is a Bad Idea. =20 Whenever there are 2 ways to do the same thing, decisions must be made = regarding the positioning of both methods in the marketplace. Specific = to this proposal, the following scenarios are possible outcomes: 1. Clients that consumers (residential, small, and medium business) = expect to interoperate in an open (not single vendor, no "check for = special restrictions") environment are unpredictable and will do one or = the other. Therefore, routers that expect to interoperate in an open = environment must do both. This outcome successfully doubles the = complexity of providing NTP info via a router, because the router must = support both DHCP and RA methods. This happened with DNS. Most routers = are supporting both ways. Ugh. But it is what it is. So with DNS the = router people bit the bullet and did double the complexity.=20 2. Routers that consumers expect to interoperate in an open environment = are unpredictable and will do one or the other. Therefore clients that = expect to interoperate in an open environment must do both. This outcome = successfully doubles the complexity of a client who needs to get NTP. = Also a bad thing.=20 3. The people who ask for the special RA capability say that the RA = capability is only for use in special closed environments, and consumers = will never find themselves confused by trying to use these devices in an = open environment. Really, it will be ok, and it will never morph into = outcome 1 or 2 above. Or outcome 4 below. We promise. 4. [my favorite] Neither clients nor routers can predict whether they = will find themselves in an environment where only one or the other is = supported. So both clients and routers that expect to be fully = interoperable must support both. The majority gets to double their = complexity. So that a minority can simplify just a little bit. =20 Barbara =20 From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of = Roger J=F8rgensen Sent: Sunday, December 25, 2011 9:06 AM To: Doug Barton Cc: 6man Mailing List; Brian E Carpenter Subject: Re: IPv6 Router Advertisement Option for Foobar Configuration =20 On Dec 23, 2011 8:57 AM, "Doug Barton" wrote: > What I *am* saying is that extending RA is always the *wrong* answer. Yes it is. Keep RA simple and lets solve "problems" elsewhere, dhcp is = the current tool. --- Roger J --- ------_=_NextPart_001_01CCCA21.BEC23E0C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m = very much opposed to extending RA for this purpose. Having 2 ways to do = the same thing serves to increase complexity of the overall ecosystem. = Unless you can guarantee that the 2nd method will only ever = be used in a closed system (network manager consciously knows that this = is the mechanism all installed devices support and will use, so that = interoperability is guaranteed). If you cannot guarantee that it will = only exist in a closed system and that no user will ever be confused, = then by introducing a 2nd method, you are increasing = complexity (more than doubling it, for this function) for the majority = of devices (that will have to implement both to be assured of = interoperability, and will have to implement “tie-breaker” = functionality as well). Doubled complexity for the majority in order to = achieve increased simplicity for a minority is a Bad = Idea.

 =

Whenever = there are 2 ways to do the same thing, decisions must be made regarding = the positioning of both methods in the marketplace. Specific to this = proposal, the following scenarios are possible = outcomes:

1. Clients = that consumers (residential, small, and medium business) expect to = interoperate in an open (not single vendor, no “check for special = restrictions”) environment are unpredictable and will do one or = the other. Therefore, routers that expect to interoperate in an open = environment must do both. This outcome successfully doubles the = complexity of providing NTP info via a router, because the router must = support both DHCP and RA methods. This happened with DNS. Most routers = are supporting both ways. Ugh. But it is what it is. So with DNS the = router people bit the bullet and did double the complexity. =

2. Routers = that consumers expect to interoperate in an open environment are = unpredictable and will do one or the other. Therefore clients that = expect to interoperate in an open environment must do both. This outcome = successfully doubles the complexity of a client who needs to get NTP. = Also a bad thing.

3. The = people who ask for the special RA capability say that the RA capability = is only for use in special closed environments, and consumers will never = find themselves confused by trying to use these devices in an open = environment. Really, it will be ok, and it will never morph into outcome = 1 or 2 above. Or outcome 4 below. We promise.

4. [my = favorite] Neither clients nor routers can predict whether they will find = themselves in an environment where only one or the other is supported. = So both clients and routers that expect to be fully interoperable must = support both. The majority gets to double their complexity. So that a = minority can simplify just a little bit.

 =

Barbara

 

From:= = ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.= org] On Behalf Of Roger J=F8rgensen
Sent: Sunday, = December 25, 2011 9:06 AM
To: Doug Barton
Cc: 6man = Mailing List; Brian E Carpenter
Subject: Re: IPv6 Router = Advertisement Option for Foobar = Configuration

 


On Dec 23, 2011 8:57 AM, = "Doug Barton" <dougb@dougbarton.us> = wrote:
<snip>
> What I *am* saying is that extending RA = is always the *wrong* answer.

Yes it is. Keep RA simple and lets solve = "problems" elsewhere, dhcp is the current = tool.

--- Roger J = ---

------_=_NextPart_001_01CCCA21.BEC23E0C-- From jared@puck.nether.net Tue Jan 3 06:17:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339BF21F84E6 for ; Tue, 3 Jan 2012 06:17:38 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkNQbQXAKvgf for ; Tue, 3 Jan 2012 06:17:37 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id ADB1A21F84B6 for ; Tue, 3 Jan 2012 06:17:37 -0800 (PST) Received: from [10.241.131.58] (m5f5f36d0.tmodns.net [208.54.95.95]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q03EGg9G000508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 09:16:47 -0500 Subject: Re: IPv6 Router Advertisement Option for Foobar Configuration Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: <750BF7861EBBE048B3E648B4BB6E8F4F21AF8700@crexc50p> Date: Tue, 3 Jan 2012 09:17:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <82609C20-FC6F-4B5C-95DF-7AF9C922C0B6@puck.nether.net> References: <7C362EEF9C7896468B36C9B79200D8350D026F16A8@INBANSXCHMBSA1.in.alcatel-lucent.com><4EF22786.2070908@dougbarton.us> <4EF2373B.6060905@gmail.com><4EF24007.3030300@dougbarton.us> <4EF258A5.1040106@gmail.com><4EF4344B.6040504@dougbarton.us> <750BF7861EBBE048B3E648B4BB6E8F4F21AF8700@crexc50p> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jan 2012 09:16:49 -0500 (EST) Cc: 6man Mailing List , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 14:17:38 -0000 On Jan 3, 2012, at 9:13 AM, STARK, BARBARA H wrote: > 4. [my favorite] Neither clients nor routers can predict whether they = will find themselves in an environment where only one or the other is = supported. So both clients and routers that expect to be fully = interoperable must support both. The majority gets to double their = complexity. So that a minority can simplify just a little bit. >=20 I have to parrot this as well. The increased complexity of IPv6 is = commonly provided as a reason that one can't deploy IPv6. - Jared= From brian@innovationslab.net Tue Jan 3 07:54:13 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC4711E8076 for ; Tue, 3 Jan 2012 07:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEsOVP+gmz-O for ; Tue, 3 Jan 2012 07:54:13 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 55A6111E8074 for ; Tue, 3 Jan 2012 07:54:13 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 0B68D88140; Tue, 3 Jan 2012 07:54:13 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AA006130002; Tue, 3 Jan 2012 07:54:12 -0800 (PST) Message-ID: <4F0324A3.6000909@innovationslab.net> Date: Tue, 03 Jan 2012 10:54:11 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Requests for agenda time X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 15:54:13 -0000 All, The scheduling of WG sessions for IETF 83 has begun. To assist the chairs in requesting the appropriate amount of time, we are soliciting requests for agenda time in Paris. As with agenda requests in the past, please send the chairs (6man-chairs@tools.ietf.org) the following information: 1. Topic 2. Presenter 3. Requested amount of time Regards, Brian & Bob From brian@innovationslab.net Tue Jan 3 08:20:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2B921F84DB; Tue, 3 Jan 2012 08:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3aAW8HgikqT; Tue, 3 Jan 2012 08:20:50 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BA19B21F84D5; Tue, 3 Jan 2012 08:20:42 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7E92D8815D; Tue, 3 Jan 2012 08:20:42 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 07C13136827A; Tue, 3 Jan 2012 08:20:41 -0800 (PST) Message-ID: <4F032AD8.70000@innovationslab.net> Date: Tue, 03 Jan 2012 11:20:40 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: 6man-ads@tools.ietf.org Subject: Request To Advance: draft-ietf-6man-3627-historic-01.txt X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg-secretary@ietf.org, ipv6@ietf.org, Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:20:51 -0000 Jari & Ralph, On behalf of the 6MAN Working Group, the chairs request the advancement of: Title : RFC3627 to Historic status Author(s) : Wesley George Filename : draft-ietf-6man-3627-historic-01.txt Pages : 4 Date : 2011-12-19 as an Informational document. The 6MAN WG Last Call ended on December 13, 2011 and this version reflects the consensus of the group. Regards, Brian & Bob From warren@kumari.net Tue Jan 3 09:00:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9676011E8080 for ; Tue, 3 Jan 2012 09:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.483 X-Spam-Level: X-Spam-Status: No, score=-106.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ou8oX3ihhRrW for ; Tue, 3 Jan 2012 09:00:27 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26511E8072 for ; Tue, 3 Jan 2012 09:00:26 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id ACA6F1B405C3; Tue, 3 Jan 2012 12:00:23 -0500 (EST) Subject: Re: IPv6 Router Advertisement Option for Foobar Configuration Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <82609C20-FC6F-4B5C-95DF-7AF9C922C0B6@puck.nether.net> Date: Tue, 3 Jan 2012 12:00:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4BFF082C-B910-4F67-BAA5-B2B81CFF9049@kumari.net> References: <7C362EEF9C7896468B36C9B79200D8350D026F16A8@INBANSXCHMBSA1.in.alcatel-lucent.com><4EF22786.2070908@dougbarton.us> <4EF2373B.6060905@gmail.com><4EF24007.3030300@dougbarton.us> <4EF258A5.1040106@gmail.com><4EF4344B.6040504@dougbarton.us> <750BF7861EBBE048B3E648B4BB6E8F4F21AF8700@crexc50p> <82609C20-FC6F-4B5C-95DF-7AF9C922C0B6@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:00:41 -0000 On Jan 3, 2012, at 9:17 AM, Jared Mauch wrote: >=20 > On Jan 3, 2012, at 9:13 AM, STARK, BARBARA H wrote: >=20 >> 4. [my favorite] Neither clients nor routers can predict whether they = will find themselves in an environment where only one or the other is = supported. So both clients and routers that expect to be fully = interoperable must support both. The majority gets to double their = complexity. So that a minority can simplify just a little bit. >>=20 >=20 > I have to parrot this as well. The increased complexity of IPv6 is = commonly provided as a reason that one can't deploy IPv6. Me too! >=20 > - Jared > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From Fred.L.Templin@boeing.com Tue Jan 3 09:09:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6EF21F85C0 for ; Tue, 3 Jan 2012 09:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdCmPPi8ZaHc for ; Tue, 3 Jan 2012 09:09:30 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 179DB21F85AD for ; Tue, 3 Jan 2012 09:09:29 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q03H9DeB021270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2012 09:09:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q03H9Doj021368; Tue, 3 Jan 2012 09:09:13 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q03H91K8021002 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 3 Jan 2012 09:09:03 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Tue, 3 Jan 2012 09:09:01 -0800 From: "Templin, Fred L" To: Brian E Carpenter , Fernando Gont Date: Tue, 3 Jan 2012 09:09:00 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczCd5vsWGp4TEupQfWxLiAPSakLswHwKIFQ Message-ID: References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> In-Reply-To: <4EF630C6.6050405@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:09:32 -0000 Hi Brian,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian E Carpenter > Sent: Saturday, December 24, 2011 12:07 PM > To: Fernando Gont > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 2011-12-24 18:34, Fernando Gont wrote: > > Hi, Florian, > >=20 > > On 12/23/2011 07:46 AM, Florian Weimer wrote: > >>> That aside, I don't know whether e.g. NAT64 or the like used this > >>> (.e.g, whether they are used for transition technologies=20 > as envisioned > >>> in RFC 2460). However, it might also be the case that such "atomic > >>> fragments" are generated when communicating through=20 > networks that do > >>> not really have a MTU >=3D 1280. In such scenarios there=20 > might be some > >>> for of gateway that sends the ICMPv6 PTB advertising a=20 > Next-Hop MTU > >>> smaller than 1280, thus resulting in atomic fragments=20 > (such that it's > >>> easier for the "gateway" to fragment the IPv6 packets). > >> Yes, this seems a plausible explanation. I wouldn't consider this > >> actual use, rather network misconfiguration. =20 > >=20 > > Why? >=20 > MTU <1280 is a complete breach of the IPv6 standard, so it is by > definition a misconfiguration. Some tunnels may not be able to provide a 1280 MTU as-seen by the inner packet, since the outer encapsulating headers may cause the packet to exceed the path MTU. Especially for nested encapsulations, a tunnel ingress may be required to use IPv6 fragmentation in order to convey 1280 and smaller packets to the tunnel egress. This is effectively a "link- specific fragmentation and reassembly ... at a layer below IPv6." IPv6 tunnel fragmentation and reassembly is explained in RFC2473, and also in draft-templin-intarea-seal: http://tools.ietf.org/html/draft-templin-intarea-seal-42 SEAL in particular solves the tunnel path MTU problem for both IPv4 and IPv6 as the outer encapsulation layer. > IPv6 requires that every link in the internet have an MTU of 1280 > octets or greater. On any link that cannot convey a 1280-octet > packet in one piece, link-specific fragmentation and=20 > reassembly must > be provided at a layer below IPv6. [RFC 2460, sectioin 5]. You stopped short quoting the final paragraph of Section 5: "In response to an IPv6 packet that is sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4), the originating IPv6 node may receive an ICMP Packet Too Big message reporting a Next-Hop MTU less than 1280." Thanks - Fred fred.l.templin@boeing.com > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From Fred.L.Templin@boeing.com Tue Jan 3 09:34:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6421F85B6 for ; Tue, 3 Jan 2012 09:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSRg8L0teJ9l for ; Tue, 3 Jan 2012 09:34:42 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9D04B21F85B5 for ; Tue, 3 Jan 2012 09:34:42 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q03HYU74027222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2012 09:34:33 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q03HYTQD014293; Tue, 3 Jan 2012 09:34:29 -0800 (PST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q03HUGvf029492 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 3 Jan 2012 09:34:23 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Tue, 3 Jan 2012 09:33:16 -0800 From: "Templin, Fred L" To: Fernando Gont , "ipv6@ietf.org" Date: Tue, 3 Jan 2012 09:33:15 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: Acy7NWKqgQ1oGlvbSD2vIbHnBS8M5QPCEypQ Message-ID: References: <4EEA0342.2040608@si6networks.com> In-Reply-To: <4EEA0342.2040608@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:34:48 -0000 Hi Fernando,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Thursday, December 15, 2011 6:25 AM > To: ipv6@ietf.org > Subject: Fragmentation-related security issues >=20 > Folks, >=20 > We have published two new IETF I-Ds about fragmentation=20 > related security > issues. >=20 > The first I-D is entitled "Security Implications of=20 > Predictable Fragment > Identification Values" > (http://tools.ietf.org/id/draft-gont-6man-predictable-fragment > -id-00.txt). > Its abstract is: >=20 > ---- cut here ---- > IPv6 specifies the Fragment Header, which is employed for the > fragmentation and reassembly mechanisms. The Fragment Header > contains an "Identification" field which, together with the IPv6 > Source Address and the IPv6 Destination Address of the packet, > identifies fragments that correspond to the same original datagram, > such that they can be reassembled together at the receiving host. > The only requirement for setting the "Identification" value is that > it must be different than that of any other fragmented packet sent > recently with the same Source Address and Destination=20 > Address. Some > implementations simply use a global counter for setting=20 > the Fragment > Identification field, thus leading to predictable values. This > document analyzes the security implications of predictable > Identification values, and updates RFC 2460 specifying additional > requirements for setting the Fragment Identification, such that the > aforementioned security implications are mitigated. > ---- cut here ---- IPsec AH/ESP provide a monotonically-incrementing per-packet sequence number. However, each packet also includes a digital signature that is used to reject spoofed packets. The same is also true of SEAL: http://tools.ietf.org/html/draft-templin-intarea-seal-42 The IPv6 Identification value could similarly be run in a monotonically-incrementing fashion also if each packet includes a digital signature. So, outer IPv6 fragmentation when IPsec or SEAL encapsulation is used should have no problems with a monotonically-incrementing Identification. Thanks - Fred fred.l.templin@boeing.com >=20 > The second I-D is entitled 'Processing of IPv6 "atomic" fragments' > (http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragment > s-00.txt). > Its abstract is: >=20 > ---- cut here ---- > IPv6 allows packets to contain a Fragment Header, without=20 > the packet > being actually fragmented into multiple pieces. Such packets > typically result from hosts that have received an ICMPv6=20 > "Packet Too > Big" error message that advertises a "Next-Hop MTU"=20 > smaller than 1280 > bytes, and are currently processed by hosts as "fragmented=20 > traffic". > By forging ICMPv6 "Packet Too Big" error messages an attacker can > cause hosts to employ "atomic fragments", and the launch any > fragmentation-based attacks against such traffic. This document > discusses the generation of the aforementioned "atomic fragments", > the corresponding security implications, and formally updates RFC > 2460 and RFC 5722 such that the attack vector based on "atomic > fragments" is completely eliminated. > ---- cut here ---- >=20 > Any feedback will be very appreciated. >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From dwing@cisco.com Tue Jan 3 09:48:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AEE21F8482 for ; Tue, 3 Jan 2012 09:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEOO2K2aK8sD for ; Tue, 3 Jan 2012 09:48:53 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD821F8481 for ; Tue, 3 Jan 2012 09:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2783; q=dns/txt; s=iport; t=1325612933; x=1326822533; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=fdUIyXAIyrr83kuOn0Ks6gYu940DR3LluxcUwclBBgw=; b=hO9KTo5okZ7ygAS4p6tYxZl1IUOgaGOSAbYd7BKLNZAdfjTh07LSx3nc ixKrHu9n4SiFE306Yup039VahaT+vXi9bPcmoEzeRURma4Ez269SWk5eF tYFN0IVdCWKPFCAZVJC2agCHODkkG1o2oDhi3RNa2WX924qCeDhElXeTI M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQBACQ/A0+tJV2c/2dsb2JhbABDggWaGYFqjlaBBYFyAQEBAwEBAQEFCgEVAkQLBQcBAwIJDgECBAEBKAcZDhUKCQgBAQQBEgsXh1gIl1QBnXWMDwSIBDOEeQGaJg X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="48361549" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 03 Jan 2012 17:48:41 +0000 Received: from dwingWS ([10.32.240.197]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q03HmeQ7004091; Tue, 3 Jan 2012 17:48:41 GMT From: "Dan Wing" To: "'Florian Weimer'" , "'Fernando Gont'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> In-Reply-To: <82fwgfk1ev.fsf@mid.bfk.de> Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 09:48:38 -0800 Message-ID: <004401ccca3f$ee4f8140$caee83c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acy+/lcm5QYA3HpPQ9mzemIv2/wFvQLOlTkw Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:48:54 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of > Florian Weimer > Sent: Tuesday, December 20, 2011 2:01 AM > To: Fernando Gont > Cc: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > * Fernando Gont: >=20 > > The second I-D is entitled 'Processing of IPv6 "atomic" fragments' > > (http://tools.ietf.org/id/draft-gont-6man-ipv6-atomic-fragments- > 00.txt). > > Its abstract is: > > > > ---- cut here ---- > > IPv6 allows packets to contain a Fragment Header, without the > packet > > being actually fragmented into multiple pieces. Such packets > > typically result from hosts that have received an ICMPv6 "Packet > Too > > Big" error message that advertises a "Next-Hop MTU" smaller than > 1280 > > bytes, and are currently processed by hosts as "fragmented > > traffic". >=20 > Does such traffic actually occur in the wild, or would it only be used > in attacks? >=20 > > By forging ICMPv6 "Packet Too Big" error messages an attacker can > > cause hosts to employ "atomic fragments", and the launch any > > fragmentation-based attacks against such traffic. This document > > discusses the generation of the aforementioned "atomic = fragments", > > the corresponding security implications, and formally updates RFC > > 2460 and RFC 5722 such that the attack vector based on "atomic > > fragments" is completely eliminated. >=20 > My feeling is that such atomic fragments should be dropped from the > protocol. >=20 > Per previous WG discussion, when reassembling such atomic fragments, > IPv6 implementations must ignore the upper 16 bits of the fragment ID > (otherwise the stateless v4/v6 gateways won't work).=20 Stateless IPv6/IPv4 translators set the upper 16 bits to 0 when=20 translating from IPv4 to IPv6; IPv6 hosts do not need to ignore=20 the upper 16 bits of the Identification field. http://tools.ietf.org/html/rfc6145#section-4.1, "Translating IPv4=20 Headers into IPv6 Headers", ... Identification: The low-order 16 bits copied from the Identification field in the IPv4 header. The high-order 16 bits set to zero. -d > Clearly, this is > not desirable. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dwing@cisco.com Tue Jan 3 11:02:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A325E802A for ; Tue, 3 Jan 2012 11:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqAllF-I1Pl9 for ; Tue, 3 Jan 2012 11:02:31 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id C53235E8028 for ; Tue, 3 Jan 2012 11:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1900; q=dns/txt; s=iport; t=1325617351; x=1326826951; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=P2xUSZCIgK4No8otsUgAl+Sgif5i0wAeZfAsMYJshPU=; b=ayBynD148cWRvJ21P4F6s9ZaIHfSqeeo4RjmJquneEYE/F+lzZvQsUJI 6V/FC+/AJjzGk2P52ZjTcXgAE+H2c4kWYhLVu/XTUvX74J8kWbamj7ZEr yaC19tcf/xioO3xmS55KO5r2PhyDqzn8sjAf7lSzl4ZYHa45I7ywA6F29 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4IANFPA09Io8UY/2dsb2JhbABDggWcBI9cgXIBAQEECAoBFQIQPw0DAgkOATcZIxsBAQQeF4dgl1MBnXqMDwSIN4R5AZom X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="2697399" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 03 Jan 2012 19:02:28 +0000 Received: from dwingWS ([10.32.240.197]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q03J2QZs005078; Tue, 3 Jan 2012 19:02:26 GMT From: "Dan Wing" To: "'Fernando Gont'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> In-Reply-To: <4F023C6B.4040401@si6networks.com> Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 11:02:23 -0800 Message-ID: <004501ccca4a$3cd1b9f0$b6752dd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczJpZJoGNNTZdAKS0CFzlYHx9huAAAjEW6g Content-Language: en-us Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:02:31 -0000 ... > > and the current IPv6 specification also allows PTB < 1280, > > http://tools.ietf.org/html/rfc2460#section-5 says: > > > > In response to an IPv6 packet that is sent to an IPv4 destination > > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > > originating IPv6 node may receive an ICMP Packet Too Big message > > reporting a Next-Hop MTU less than 1280. In that case, the IPv6 > node > > is not required to reduce the size of subsequent packets to less > than > > 1280, but must include a Fragment header in those packets so that > the > > IPv6-to-IPv4 translating router can obtain a suitable > Identification > > value to use in resulting IPv4 fragments. Note that this means > the > > payload may have to be reduced to 1232 octets (1280 minus 40 for > the > > IPv6 header and 8 for the Fragment header), and smaller still if > > additional extension headers are used. > > Exactly. And my question was about whether the "atomic fragments" that > were found in the wild were the result of translators, or of IPv6 > networks that "violate" the standard and do not support an MTU of >= > 1280. Dunno. I am only trying to point out that IPv6 hosts need to handle receiving ICMP packet-too-big of less than 1280, because we are going to see more stateless IPv6/IPv4 translators. If IPv6 hosts don't handle ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators won't work with sub-1280 MTU IPv4 paths. And Ran has pointed out other deployments where sub-1280 MTUs are being used on IPv6. (An aside comment: I wonder if those networks can use LFI (link fragmentation and interleaving), which allows preserving the layer 3 MTU and should also provide the smaller packets needed by the layer 1 or 2 network). So, I don't think we can just wish away packet-too-big < 1280. -d From alexandru.petrescu@gmail.com Tue Jan 3 12:16:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE45321F85A9 for ; Tue, 3 Jan 2012 12:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgIPEQY90FY1 for ; Tue, 3 Jan 2012 12:16:58 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C89C821F85A5 for ; Tue, 3 Jan 2012 12:16:57 -0800 (PST) Received: by wibhj6 with SMTP id hj6so11757196wib.31 for ; Tue, 03 Jan 2012 12:16:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Jy8T/HcDblt5jqxxQxvieKNjnN2hXWBSpiXvRkKYJ9I=; b=txHSWdWBNdcPPt63379JhBdp07iuPCw6ezMuX0iju5abrFj91+tpUpFtYTI/NmtFVX 7rc4s9NnvGZiRZp+M9FPnigdnnl/2UJP5bghHSgA+Nyz3ArtZsOMo+5L/BN/tZtEnRAg HJBx2qTLppLJz8gTb4RSRBbHcwGLlVA9ENW18= Received: by 10.180.93.193 with SMTP id cw1mr82808027wib.5.1325621816791; Tue, 03 Jan 2012 12:16:56 -0800 (PST) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id k33sm14062974wbo.5.2012.01.03.12.16.54 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 12:16:55 -0800 (PST) Message-ID: <4F036234.6030906@gmail.com> Date: Tue, 03 Jan 2012 21:16:52 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Prefix Delegation questions References: <16389D46-2D57-4999-A017-93D4B1DCA17B@employees.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:16:59 -0000 Le 03/01/2012 09:50, Ming-Hong Wu a écrit : > First, thanks! > > By "what protocols should support PD", I mean, PD sounds like a > mechanism: to delegate a prefix. Like RFC 3769, I can't make sure how > it is achieved. > > As you said, RFC 3633 is a protocol, like an extension of DHCPv6 that > can do PD. > > Thanks again for your reply and the answer of DHCPv6 is exactly what > I want to confirm :-) I'm just curious that except DHCPv6, if there > is existing any other protocol for PD implementation. At IETF talk, often "Prefix Delegation" means precisely DHCPv6-PD RFC3633 and nothing else. But still at IETF, there exist other mechanisms which could be used to "offer" ("delegate", "assign", "allocate", "configure" ?) a prefix to a Router. For example, for IPv4 "subnet allocation" is also a DHCP but v4 option (not v6), as discussed in draft-ietf-dhc-subnet-alloc. There is also a PMIPv6 RFC5213 non-DHCP mechanism which is used by an LMA entity (Local Mobility Anchor) to assign a Home Network Prefix to a Mobile Node. Once assigned, the MH could do whatever with parts of it, including use on its ingress interface(s). Work more or less recent proposes OSPF to do "prefix assignment" in draft-arkko-homenet-prefix-assignment-01. Even Router Renumbering RFC2894 can be considered to "assign" prefixes to links, even if actually it "changes" the prefix of a link into another prefix. And then there is also HMIPv6 and maybe some AAA Diameter or EAP option which may include some prefix to be assigned, not to mention IKEv2 and more. Yours, Alex > > 2012/1/3 Ole Troan > > >> I know Prefix Delegation. I want to know if there is any RFC > / specification said that what protocols should support PD. > > RFC3633 / RFC6204. RFC3633 _is_ a protocol. I don't understand what > you mean by "what protocols should support PD". > >> Let's say we have a router supporting 1 WAN and 1 LAN. > Suppose the WAN acquires an prefix (with 64 length) and forms >> its WAN IP. LAN-side users still can't access IPv6 Internet, right >> ? > > PD delegates a prefix to the LAN-side links, not the WAN side. for > the WAN side normal address assignment is used (SLAAC, DHCP). > >> As I know, the router must request for another prefix (e.g. > 2001:1234:5678::/48) and assign a suitable prefix (e.g. > 2001:1234:5678:ABCD::/64) >> to its LAN, by using Radvd to advertise this prefix. Then, the > LAN-side users can access IPv6 Internet. >> >> >> If above assumption is wrong, please correct me. Otherwise, I > want to make sure, what available methods >> can the router use to request the prefix, 2001:1234:5678::/48 ? > DHCPv6 is the only solution ? Any other ? > > yes, your assumption is wrong. corrected. > > DHCPv6 (RFC3633) is the only IETF specified protocol mechanism for > prefix delegation. you can possibly do it with TR-69, DOCSIS or > manual configuration. > > cheers, Ole > > > > > -- Sincerely, minhong > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Jan 3 12:24:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF52011E80F0 for ; Tue, 3 Jan 2012 12:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.427 X-Spam-Level: X-Spam-Status: No, score=-103.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wra9LZtDKxO for ; Tue, 3 Jan 2012 12:24:09 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2939F11E80F7 for ; Tue, 3 Jan 2012 12:24:09 -0800 (PST) Received: by iabz21 with SMTP id z21so10223130iab.31 for ; Tue, 03 Jan 2012 12:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=IoNlP6EbxwkBr6JeUCKTOLdHH3qzYhLKWlniIEBVtzs=; b=LT3qfexQZT37sdi4NNvALcsvRPQTVfcB1tbYrB4dePz9DaibbsoeNFImNDZRHd7E0k FN+HVgrhcRfjMMoUoDcndXUyICEhqPHJOoCZiKL9Yw+HFb9JYEMDD27V5pI7CQAFXZf8 7Ti4U2MRsm47RXgtghI917Rx13C+7m3/wOqF4= Received: by 10.50.217.168 with SMTP id oz8mr63967925igc.24.1325622248828; Tue, 03 Jan 2012 12:24:08 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id 5sm3250942ibe.8.2012.01.03.12.24.05 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 12:24:07 -0800 (PST) Message-ID: <4F0363E3.2010902@gmail.com> Date: Wed, 04 Jan 2012 09:24:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> In-Reply-To: <004501ccca4a$3cd1b9f0$b6752dd0$@com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:24:09 -0000 On 2012-01-04 08:02, Dan Wing wrote: > ... >>> and the current IPv6 specification also allows PTB < 1280, >>> http://tools.ietf.org/html/rfc2460#section-5 says: >>> >>> In response to an IPv6 packet that is sent to an IPv4 destination >>> (i.e., a packet that undergoes translation from IPv6 to IPv4), the >>> originating IPv6 node may receive an ICMP Packet Too Big message >>> reporting a Next-Hop MTU less than 1280. In that case, the IPv6 >> node >>> is not required to reduce the size of subsequent packets to less >> than >>> 1280, but must include a Fragment header in those packets so that >> the >>> IPv6-to-IPv4 translating router can obtain a suitable >> Identification >>> value to use in resulting IPv4 fragments. Note that this means >> the >>> payload may have to be reduced to 1232 octets (1280 minus 40 for >> the >>> IPv6 header and 8 for the Fragment header), and smaller still if >>> additional extension headers are used. >> Exactly. And my question was about whether the "atomic fragments" that >> were found in the wild were the result of translators, or of IPv6 >> networks that "violate" the standard and do not support an MTU of >= >> 1280. > > Dunno. > > I am only trying to point out that IPv6 hosts need to handle receiving > ICMP packet-too-big of less than 1280, because we are going to see > more stateless IPv6/IPv4 translators. If IPv6 hosts don't handle > ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators > won't work with sub-1280 MTU IPv4 paths. > > And Ran has pointed out other deployments where sub-1280 MTUs are > being used on IPv6. (An aside comment: I wonder if those networks > can use LFI (link fragmentation and interleaving), which allows > preserving the layer 3 MTU and should also provide the smaller > packets needed by the layer 1 or 2 network). > > So, I don't think we can just wish away packet-too-big < 1280. Sadly, that seems to be true unless we make a much more radical change, because of translators. Brian From dwing@cisco.com Tue Jan 3 12:43:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7370211E8106 for ; Tue, 3 Jan 2012 12:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV5fJ+HaSPjz for ; Tue, 3 Jan 2012 12:43:06 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 286FB11E80B2 for ; Tue, 3 Jan 2012 12:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3371; q=dns/txt; s=iport; t=1325623386; x=1326832986; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=9m89RM9wR/9xLCDgRt3UZ9eBncJ9J6+IZfWTbjx4ngg=; b=AAghLzDw/mTw8KzGWo1COa1OCJanTGIDv8mdWrv9tFVbyHWyYz/SRVhI oTBp+E1sxfewob2bd2mhBenCiexGfEAE+0BRAp3jjcZ+kI8WKt6zQm50R ZjEJQAw+nZH7B909WYOGIN4iRJjIRIlWpViYHhizCOdwNLXNLNHwEYayT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8JAL1nA0+rRDoG/2dsb2JhbABCggWDC5h6jleBBYFyAQEBBAgKARAHPhEMAQMCCQ8CBAEBAQICIwMCAhkIGwoJCAEBBBMLF4dgl0cBjFuRJoEviUqBFgSIN4R5AZJAh2Y X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="23642087" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 03 Jan 2012 20:43:06 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q03Kh5De029270; Tue, 3 Jan 2012 20:43:05 GMT From: "Dan Wing" To: "'Brian E Carpenter'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> In-Reply-To: <4F0363E3.2010902@gmail.com> Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 12:43:03 -0800 Message-ID: <01f701ccca58$4b7bd040$e27370c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczKVacEIZXHn64pR7CPE0lyItw5iQAAI6ew Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:43:07 -0000 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: Tuesday, January 03, 2012 12:24 PM > To: Dan Wing > Cc: 'Fernando Gont'; 'Fernando Gont'; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > On 2012-01-04 08:02, Dan Wing wrote: > > ... > >>> and the current IPv6 specification also allows PTB < 1280, > >>> http://tools.ietf.org/html/rfc2460#section-5 says: > >>> > >>> In response to an IPv6 packet that is sent to an IPv4 > destination > >>> (i.e., a packet that undergoes translation from IPv6 to IPv4), > the > >>> originating IPv6 node may receive an ICMP Packet Too Big message > >>> reporting a Next-Hop MTU less than 1280. In that case, the IPv6 > >> node > >>> is not required to reduce the size of subsequent packets to less > >> than > >>> 1280, but must include a Fragment header in those packets so > that > >> the > >>> IPv6-to-IPv4 translating router can obtain a suitable > >> Identification > >>> value to use in resulting IPv4 fragments. Note that this means > >> the > >>> payload may have to be reduced to 1232 octets (1280 minus 40 for > >> the > >>> IPv6 header and 8 for the Fragment header), and smaller still if > >>> additional extension headers are used. > >> Exactly. And my question was about whether the "atomic fragments" > that > >> were found in the wild were the result of translators, or of IPv6 > >> networks that "violate" the standard and do not support an MTU of >= > >> 1280. > > > > Dunno. > > > > I am only trying to point out that IPv6 hosts need to handle > receiving > > ICMP packet-too-big of less than 1280, because we are going to see > > more stateless IPv6/IPv4 translators. If IPv6 hosts don't handle > > ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators > > won't work with sub-1280 MTU IPv4 paths. > > > > And Ran has pointed out other deployments where sub-1280 MTUs are > > being used on IPv6. (An aside comment: I wonder if those networks > > can use LFI (link fragmentation and interleaving), which allows > > preserving the layer 3 MTU and should also provide the smaller > > packets needed by the layer 1 or 2 network). > > > > So, I don't think we can just wish away packet-too-big < 1280. > > Sadly, that seems to be true unless we make a much more radical change, > because of translators. Or, we declare a new restriction that translators are not expected to work if the IPv4 network has an MTU less than 1260 (1260=1280-20, because IPv6 header is 20B bigger than IPv4 header). I don't know if there is consensus for such a restriction. To date, both RFC2765 and RFC6145 avoided such a restriction. However, if there are widespread IPv6 host implementations or firewalls that erroneously filter or ignore ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to accept that restriction, and modify their IPv4 networks to have MTU>=1260. Such IPv4 network modifications would add to further pain to IPv6 coexistence. MTU research by Ben Stasiewicz and Matthew Luckie (WAND), published and presented at RIPE and other conferences, shows a 2-3% failure rate to various popular web sites. They did additional testing during World IPv6 Day, but I haven't dug into those results yet. -d From jared@puck.nether.net Tue Jan 3 12:53:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43711E810F for ; Tue, 3 Jan 2012 12:53:43 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RgBjRO6PwM7 for ; Tue, 3 Jan 2012 12:53:42 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id B624E11E810C for ; Tue, 3 Jan 2012 12:53:42 -0800 (PST) Received: from [10.31.201.15] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q03Kqx8N013598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 15:53:00 -0500 Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <4F0363E3.2010902@gmail.com> Date: Tue, 3 Jan 2012 15:53:48 -0500 Content-Transfer-Encoding: 7bit Message-Id: <207122C3-5701-4708-B0FA-C527114DA79D@puck.nether.net> References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jan 2012 15:53:00 -0500 (EST) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:53:43 -0000 On Jan 3, 2012, at 3:24 PM, Brian E Carpenter wrote: >> >> So, I don't think we can just wish away packet-too-big < 1280. > > Sadly, that seems to be true unless we make a much more radical change, > because of translators. Sometimes presenting broken networks and hosts a non-working solution is the proper signaling mechanism to inform them they need to take corrective action. This is done by placing infected hosts in a walled-garden in some cases, or perhaps here, if they can't handle anything lt 1280, they need to repair or patch their host/stack. At some point these legacy networks need to be taken off life-support. - Jared From dougb@dougbarton.us Tue Jan 3 13:00:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BDB11E80BB for ; Tue, 3 Jan 2012 13:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdf4KxxmnEwt for ; Tue, 3 Jan 2012 13:00:02 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id C47B811E811B for ; Tue, 3 Jan 2012 12:59:46 -0800 (PST) Received: (qmail 27592 invoked by uid 399); 3 Jan 2012 20:59:41 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 3 Jan 2012 20:59:41 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F036C3B.5030403@dougbarton.us> Date: Tue, 03 Jan 2012 12:59:39 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Dan Wing Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> In-Reply-To: <004501ccca4a$3cd1b9f0$b6752dd0$@com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:00:03 -0000 On 01/03/2012 11:02, Dan Wing wrote: > If IPv6 hosts don't handle > ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators > won't work with sub-1280 MTU IPv4 paths. ... and this is not a feature because? And no, don't quote the robustness principle. The floor for MTU has been hard-coded since day 1, so anyone who breaks that deserves what they get. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From jared@puck.nether.net Tue Jan 3 13:00:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567E311E80BB for ; Tue, 3 Jan 2012 13:00:44 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjQVoYDOyNx9 for ; Tue, 3 Jan 2012 13:00:44 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D518211E80B9 for ; Tue, 3 Jan 2012 13:00:43 -0800 (PST) Received: from [10.31.201.15] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q03KxweA014376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 15:59:59 -0500 Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <4F036C3B.5030403@dougbarton.us> Date: Tue, 3 Jan 2012 16:00:48 -0500 Content-Transfer-Encoding: 7bit Message-Id: <36A1BBEE-0EEA-485C-A2A6-55A639D3415B@puck.nether.net> References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F036C3B.5030403@dougbarton.us> To: Doug Barton X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jan 2012 15:59:59 -0500 (EST) Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:00:44 -0000 On Jan 3, 2012, at 3:59 PM, Doug Barton wrote: > ... and this is not a feature because? And no, don't quote the > robustness principle. The floor for MTU has been hard-coded since day 1, > so anyone who breaks that deserves what they get. +1 From evyncke@cisco.com Tue Jan 3 13:52:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3821C11E80DA for ; Tue, 3 Jan 2012 13:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ra7KrrxYWPiM for ; Tue, 3 Jan 2012 13:52:54 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3B11E80AC for ; Tue, 3 Jan 2012 13:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=832; q=dns/txt; s=iport; t=1325627574; x=1326837174; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=T//ucafJw16mZFaronVUjH/7hq1iHhjH+d8GoXgR0ZE=; b=kowXLXUW/gI1+CSbFpqT8mNd0fZaKSBlhvQiuQk40R9VEEO5+dA/Mquk rZFIDCNarvzt8kmsV6rKGaRa3s9giHoAzMSQOfoGJJif8+o4mQmn+nxDY 8Ji0zz8YR+nDVRmpmG2USjy9F1dJmAZbOACM5uNDQ/KICaUc+OHuUmK07 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQIAAB4A0+Q/khM/2dsb2JhbABCggWqXIEFgXIBAQEEEgEdSQUHBAIBCBUNBhcBBgFFEQEBBBMIGp8WAZ4FiyxjBIgEnzM X-IronPort-AV: E=Sophos;i="4.71,452,1320624000"; d="scan'208";a="62670659" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 03 Jan 2012 21:52:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q03Lqr7s024599 for ; Tue, 3 Jan 2012 21:52:53 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 22:52:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 22:52:44 +0100 Message-ID: <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> In-Reply-To: <004501ccca4a$3cd1b9f0$b6752dd0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fragmentation-related security issues Thread-Index: AczJpZJoGNNTZdAKS0CFzlYHx9huAAAjEW6gAAvmxDA= References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar><002f01ccc9a2$9fab9990$df02ccb0$@com><4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> From: "Eric Vyncke (evyncke)" To: "Dan Wing (dwing)" X-OriginalArrivalTime: 03 Jan 2012 21:52:53.0081 (UTC) FILETIME=[0B394490:01CCCA62] Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:52:56 -0000 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of Dan > Wing (dwing) =20 > So, I don't think we can just wish away packet-too-big < 1280. =20 Rather than dropping those ICMP PTB, let's accept them but let the OS = decide which is the minimum size path MTU that it can accept/tolerate... = - For a server, this min path MTU should be large (to avoid DoS) - For a host, this min path MTU could be small Of course, if the path is symmetric, the path MTU will be the same on = both direction (assuming everything is well configured). OTOH, as written by Jared, let's fail it hard so it is noticeable by the = user is another technique... but with a dual-stack and happy eye-ball, = the end-user will notice nothing and will stay happy with IPv4. -=E9ric From dougb@dougbarton.us Tue Jan 3 14:45:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C601F0C46 for ; Tue, 3 Jan 2012 14:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hczkd9iZ3lqB for ; Tue, 3 Jan 2012 14:45:31 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id E96091F0C44 for ; Tue, 3 Jan 2012 14:45:30 -0800 (PST) Received: (qmail 21175 invoked by uid 399); 3 Jan 2012 22:45:26 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 3 Jan 2012 22:45:26 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F0384FD.6060209@dougbarton.us> Date: Tue, 03 Jan 2012 14:45:17 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Eric Vyncke (evyncke)" Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar><002f01ccc9a2$9fab9990$df02ccb0$@com><4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> In-Reply-To: <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:45:31 -0000 On 01/03/2012 13:52, Eric Vyncke (evyncke) wrote: > Rather than dropping those ICMP PTB, let's accept them but let the OS decide which is the minimum size path MTU that it can accept/tolerate... As someone who works for a router company I can see why the "punt it to the OS" option seems attractive. :) As an OS person my response is that having a well-enforced minimum makes code simpler. Simple is good. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From pch-b29AA871B@u-1.phicoh.com Tue Jan 3 14:57:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB63021F84B6 for ; Tue, 3 Jan 2012 14:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh5Oa+1XSzms for ; Tue, 3 Jan 2012 14:57:32 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2311E21F84B4 for ; Tue, 3 Jan 2012 14:57:27 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RiDIK-0001ZlC; Tue, 3 Jan 2012 23:57:24 +0100 Message-Id: To: RJ Atkinson Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> In-reply-to: Your message of "Tue, 3 Jan 2012 07:32:17 -0500 ." <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> Date: Tue, 03 Jan 2012 23:57:23 +0100 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:57:32 -0000 In your letter dated Tue, 3 Jan 2012 07:32:17 -0500 you wrote: >Of course an adaptation layer has various costs >beyond a single bit, but please also consider the >case where there are no unused bits at hand. Well, Van Jacobson made his header compression work with SLIP. And everybody was happy. >The choice of minimum IPv6 Link MTU is necessarily >somewhat arbitrary. Different numbers are optimal >for different deployments. It is merely sad that >the IETF chose such a large number. > >The other approach I've heard about being taken >for working over small MTU links is simply to >perform (one-way) IPv6->IPv4 protocol translation, >since IPv4 works natively on links that small. >It seems sad that the IETF decision is pushing >people towards a protocol translation approach. What I see in IPv4 PMTU and also IPv6 PMTU is: - it just doesn't work reliably. - for IPv4 MSS clamping is widespread to make TCP work. and UDP just gets fragmented. - For IPv6, given that the host has to do the fragmentation, a big minimum MTU is required. Otherwise, too much stuff will end up being fragmented at 576. My guess is, that anybody who is running a links at less than 1280 is just going to get a lot of trouble. That applies both to the links you mentioned and any IPv6-to-IPv4 translators. Most IPv4 links are bigger than 1280. So, those translators will seem to work in most cases. IPv4 links smaller than 1280 will just see failures that are quite hard to debug. From fgont@si6networks.com Tue Jan 3 15:40:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7E11F0C46 for ; Tue, 3 Jan 2012 15:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-1.537, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO19essxXGrs for ; Tue, 3 Jan 2012 15:40:41 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id A40F11F0C44 for ; Tue, 3 Jan 2012 15:40:40 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiDxb-0001Sg-Sd; Wed, 04 Jan 2012 00:40:09 +0100 Message-ID: <4F028C42.1020702@si6networks.com> Date: Tue, 03 Jan 2012 02:04:02 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:40:44 -0000 Hi, Bjoern, On 01/02/2012 07:10 PM, Bjoern A. Zeeb wrote: > Contrary to how a lot of people seem to read RFC 2460, especially the last > paragraph of section 5 (also subject to Florian's Errata 2843), I basically > read (in) the past: > > 4.5 "The Fragment header is used by an IPv6 source to send a packet larger > than would fit in the path MTU to its destination." > > ``You shall not add a fragment header unless you really need to''. Well, it's supposedly (specs-wise) also used to help translating devices in the fragmentation of packets... > The only way you must add a fragment header for a packet size below 1280 is > when it is a packet going to a v4 destination (i.e. say through NAT64 these > days). How you can track this (if you can) and how you get that information > is beyond the scope of 2460 but you need to know to be able to. Otherwise > you shall not. That's not what the specs state. The specs say that if you receive an ICMPv6 PTB advertising an MTU <= you need not fragment, but should include a fragment header. > This is the reason ipfw originally dropped what people now seem to call > "atomic fragments". Well, it's a useful short-hand for "packets that hace a fragment offset of zero and for which the M bit is not set".. ;-) > When I PR started to look at the PR I consulted briefly with Bob and the > outcome of the short exchange for me was: > > - the "atomic frags" do not seem to hurt in this particular filtering case > and could possibly be allowed. Atomic fragments could be safely processed as if they were not fragmented traffic at all... see the I-D we published... > While I still feel that these "atomic frags" should be sent to the packet > shredder on first sight it seemed to match reality (and especially > operational impact) better. However I left a sysctl for individuals to > control their preference. ANy comments regarding processing them as non-fragmented traffic, as noted in draft-gont-6man-ipv6-atomic-fragments ? > Another thing on the "atomic frags" I was (partly) shown was that they seemed > to have a length in the 50 octets size which would even be way below other > minimums. So I am really not feeling too confident that it's not just silly > stacks or software bugs and it would really be thrilling if people could figure > out OS and version and reason why some systems send them. Well I'm certainly am after that. However, the point is that we need not over-engineer this one: these atomic fraggments could be safely processed without running into the typical IP fragmentation issues... > On the entire "fragmentation related security issues" topic, I feel we are > seriously heading into wrong directions to just more complications rather than > simplifications. > > The idea of having the fragment offset to stay compatible the way things worked > in IPv4 certainly was a great idea and has later proven to be a PITA. What I'd > really like to have is a silly fragment counter 1..n, so no overlapping possible > (and not just not allowed on paper anymore as that does not remove that code > to check from the stacks), simple handling of duplicate fragments, and no > "atomic frags" allowed. That makes a bunch of IP fragmentation attacks (mostly DoS) trivial... -- we should have learnt the leason from IPv4, shouldn't we? > Luckily the fragment header still has a lot of spare space that could allow > to indicate which scheme is used and dropping a packet unless a bit is set > (not being set indicating the old scheme) is really easy to implement, esp. > after a transition period and ripping the old code out would be as well then;-) > I 'd really not want to add even more complicated house keeping and stuff > long term. You're already in a complicated position as a result of predictable I-Ds OpenBSD randomized them, OpenSolaris implemented the scheme that is descrivbed in the I-D I published... what's the big deal about it? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Jan 3 15:40:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F56011E808E for ; Tue, 3 Jan 2012 15:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=-1.152, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrRL3lmMxBNW for ; Tue, 3 Jan 2012 15:40:49 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id B8C0B11E808A for ; Tue, 3 Jan 2012 15:40:49 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiDxy-0001TE-Li; Wed, 04 Jan 2012 00:40:27 +0100 Message-ID: <4F028C9B.4010704@si6networks.com> Date: Tue, 03 Jan 2012 02:05:31 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:40:50 -0000 On 01/02/2012 07:48 PM, Bjoern A. Zeeb wrote: > You'd need to go to the origins most likely and get into touch with them, > ask them, work with them to identify things and see if you can find a > common denominator... > > It might really be worth doing so; in case we are hunting misconfigurations > or bugs here and discussing the merits on how to handle other than drop;-) Why should you drop in this case, when it's trivial to process these fragments safely, with no side effects?? -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bzeeb-lists@lists.zabbadoz.net Tue Jan 3 15:52:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283D421F85AD for ; Tue, 3 Jan 2012 15:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnfzya9ahTvm for ; Tue, 3 Jan 2012 15:51:59 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 9720F21F85A3 for ; Tue, 3 Jan 2012 15:51:58 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3184E25D37C7; Tue, 3 Jan 2012 23:51:57 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 5EC27BD86B0; Tue, 3 Jan 2012 23:51:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id fPcAOexGaFtN; Tue, 3 Jan 2012 23:51:55 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 54EB9BD86AE; Tue, 3 Jan 2012 23:51:55 +0000 (UTC) Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F028C9B.4010704@si6networks.com> Date: Tue, 3 Jan 2012 23:51:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <298C387E-66C2-4558-8ACF-441A56A7D501@lists.zabbadoz.net> References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:52:00 -0000 On 3. Jan 2012, at 05:05 , Fernando Gont wrote: > On 01/02/2012 07:48 PM, Bjoern A. Zeeb wrote: >> You'd need to go to the origins most likely and get into touch with = them, >> ask them, work with them to identify things and see if you can find a >> common denominator... >>=20 >> It might really be worth doing so; in case we are hunting = misconfigurations >> or bugs here and discussing the merits on how to handle other than = drop;-) >=20 > Why should you drop in this case, when it's trivial to process these > fragments safely, with no side effects?? Because a fragment header that's not needed a) heats the planet, b-z) = does all the things what that means. The more we can force that not to = happen the better we are off. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From fgont@si6networks.com Tue Jan 3 16:03:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1345F1F0C74 for ; Tue, 3 Jan 2012 16:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.93 X-Spam-Level: X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwQc3Fxua-sV for ; Tue, 3 Jan 2012 16:03:53 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8D1F0C57 for ; Tue, 3 Jan 2012 16:03:53 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiE0H-0001Ug-JY; Wed, 04 Jan 2012 00:42:49 +0100 Message-ID: <4F038BD2.6080805@si6networks.com> Date: Tue, 03 Jan 2012 20:14:26 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Atomic fragments: converging on something? X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:03:54 -0000 Folks, The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered some (unintended) discussion about the usefulness/legitimacy of IPv6 "atomic fragments" (IPv6 packets that contain a Fragmentation Header, but that have the "More Fragments" bit set to zero). My understanding is that is quite clear that such packets have been found in the wild and that a number of things would break if they were blocked or banned. That said, I'd like some feedback on the actual proposal in draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned "atomic fragments" as if they were non-fragmented packets. This would basically eliminate all the security issues and problems normally associated with framgentation, while still allowing their legitimate use. Thoughts? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Tue Jan 3 16:03:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A97D1F0C57 for ; Tue, 3 Jan 2012 16:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMJuIfb+1Kpm for ; Tue, 3 Jan 2012 16:03:53 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 913D51F0C70 for ; Tue, 3 Jan 2012 16:03:53 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiDyd-0001TX-4w; Wed, 04 Jan 2012 00:41:07 +0100 Message-ID: <4F036A8A.9000806@si6networks.com> Date: Tue, 03 Jan 2012 17:52:26 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <82sjjxqisl.fsf@mid.bfk.de> In-Reply-To: <82sjjxqisl.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:03:54 -0000 Florian, On 01/03/2012 05:42 AM, Florian Weimer wrote: >>>> not really have a MTU >= 1280. In such scenarios there might be some >>>> for of gateway that sends the ICMPv6 PTB advertising a Next-Hop MTU >>>> smaller than 1280, thus resulting in atomic fragments (such that it's >>>> easier for the "gateway" to fragment the IPv6 packets). >>> >>> Yes, this seems a plausible explanation. I wouldn't consider this >>> actual use, rather network misconfiguration. >> >> Why? > > What Brian said---IPv6 is supposed to have a lower bound on the MTU. > I just don't think it's a good idea to through that out of the window > because there are genuine advantages. Again: the v6 core spec mentions a possible scenarion in which you might legitimately receive CIMP PTBs that advertise an MTU smaller than 1280 bytes. In that case, you're not required to split your packets into fragments smaller or equal to 1280 bytes, but *are* required to react by including a Fragment Header in subsequent packets. >>> In my opinion, we need >>> more evidence that these fragments actually serve a useful purpose. >>> >>>> That aside, there's the proposal by Mark Andrews which would add yet >>>> another use case for these atomic fragments. >>> >>> Not really. It's a workaround so that stateless IPv6 services are >>> possible, despite this protocol weiredness. >> >> Not sure what you mean. > > Without the API change in draft-andrews-6man-force-fragmentation, it is > flat out impossible to server IPv6 traffic in a stateless fashion. The > stack is required to keep a per-destination cache which records the > necessity of a fragment extension header, even if the application never > sends any packets larger than 1280 bytes. The stack is required to have a Destination Cache, anyway. >> Sorry, I cannot see why some packets would require going through a >> translator, while others wouldn't. > > The joy of packet switching. 8-) If a packet is actually destined to the IPv4 world (and hence needs to go through a translator), it will need to cross one translator, or another... but *some* translator. >> That is, if the intended destination is really a v4 node, all packets >> meant to it will go through a translator, If it's not, none will. > > If the target is a v4 node, surely the network can just fragment as > needed, and reassemble using the v4 fragmentation information? That's > why I assumed the actual use case has to be more complicated (such as > translation back to v6). Then you'd need the translator to be stateful, such that it can selecct appropriate Identification values (i.e., not reuse them too quickly). > I'm attempting a reductio ad absurdum here---trying to show that for all > potential use cases of atomic fragments, there are much simpler > alternatives, and the remaining ones are utterly bizarre and not worth > supporting. We're not designing for the future. We're *currently* using/seeing atomic fragments. If you plan to ban them, that comes at the cost of breaking stuff. That aside, atomic fragments can be handled as safely as non-fragmented traffic: *that* was the motivation of the publication of draft-gont-6man-ipv6-atomic-fragments Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bzeeb-lists@lists.zabbadoz.net Tue Jan 3 16:22:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5022B21F855F for ; Tue, 3 Jan 2012 16:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H54CaAhM0AqO for ; Tue, 3 Jan 2012 16:22:47 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 6292821F84F7 for ; Tue, 3 Jan 2012 16:22:44 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 4FC8525D386D; Wed, 4 Jan 2012 00:22:42 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 11467BD7704; Wed, 4 Jan 2012 00:22:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 0IP3BE4B91Da; Wed, 4 Jan 2012 00:22:41 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 9497CBD7702; Wed, 4 Jan 2012 00:22:35 +0000 (UTC) Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F028C42.1020702@si6networks.com> Date: Wed, 4 Jan 2012 00:22:35 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <4F028C42.1020702@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:22:48 -0000 On 3. Jan 2012, at 05:04 , Fernando Gont wrote: >> The idea of having the fragment offset to stay compatible the way = things worked >> in IPv4 certainly was a great idea and has later proven to be a PITA. = What I'd >> really like to have is a silly fragment counter 1..n, so no = overlapping possible >> (and not just not allowed on paper anymore as that does not remove = that code >> to check from the stacks), simple handling of duplicate fragments, = and no >> "atomic frags" allowed. >=20 > That makes a bunch of IP fragmentation attacks (mostly DoS) trivial... > -- we should have learnt the leason from IPv4, shouldn't we? More than knowing all the fragment offsets upfront with the first packet for almost all implementations? Seriously? Who implements packet size randomizations for fragments to avoid that? >> Luckily the fragment header still has a lot of spare space that could = allow >> to indicate which scheme is used and dropping a packet unless a bit = is set >> (not being set indicating the old scheme) is really easy to = implement, esp. >> after a transition period and ripping the old code out would be as = well then;-) >> I 'd really not want to add even more complicated house keeping and = stuff >> long term. >=20 > You're already in a complicated position as a result of predictable = I-Ds >=20 > OpenBSD randomized them, Yeah and so do other BSDs derived from KAME... ( = http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c#re= v1.397 ) > OpenSolaris implemented the scheme that is > descrivbed in the I-D I published... what's the big deal about it? ... but the above was not about the Identification field. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!= From marka@isc.org Tue Jan 3 16:55:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7768D11E80B9 for ; Tue, 3 Jan 2012 16:55:26 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooNLAgXpXFpI for ; Tue, 3 Jan 2012 16:55:26 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E384211E8093 for ; Tue, 3 Jan 2012 16:55:25 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id D073AC9476; Wed, 4 Jan 2012 00:55:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:157:6bc5:2c94:be00]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 927F5216C6A; Wed, 4 Jan 2012 00:55:09 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 090331AC7C8C; Wed, 4 Jan 2012 11:55:10 +1100 (EST) To: "Bjoern A. Zeeb" From: Mark Andrews References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <298C387E-66C2-4558-8ACF-441A56A7D501@lists.zabbadoz.net> Subject: Re: Fragmentation-related security issues In-reply-to: Your message of "Tue, 03 Jan 2012 23:51:54 -0000." <298C387E-66C2-4558-8ACF-441A56A7D501@lists.zabbadoz.net> Date: Wed, 04 Jan 2012 11:55:09 +1100 Message-Id: <20120104005510.090331AC7C8C@drugs.dv.isc.org> Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:55:26 -0000 In message <298C387E-66C2-4558-8ACF-441A56A7D501@lists.zabbadoz.net>, "Bjoern A . Zeeb" writes: > On 3. Jan 2012, at 05:05 , Fernando Gont wrote: > > > On 01/02/2012 07:48 PM, Bjoern A. Zeeb wrote: > >> You'd need to go to the origins most likely and get into touch with them, > >> ask them, work with them to identify things and see if you can find a > >> common denominator... > >> > >> It might really be worth doing so; in case we are hunting misconfiguration > s > >> or bugs here and discussing the merits on how to handle other than drop;-) > > > > Why should you drop in this case, when it's trivial to process these > > fragments safely, with no side effects?? > > Because a fragment header that's not needed a) heats the planet, b-z) does > all the things what that means. The more we can force that not to happen > the better we are off. Atomic fragments > 1280 should not appear in the network. Atomic fragments <= 1280 are a expected part of the IPv6 landscape. For TCP they should be rare. For UDP it depends on the protocol running on top of UDP. PMTUD relying on PTB is just not reliable. > -- > Bjoern A. Zeeb You have to have visions! > It does not matter how good you are. It matters what good you do! > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From dwing@cisco.com Tue Jan 3 17:22:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F911E8093 for ; Tue, 3 Jan 2012 17:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPLHabmDaSf2 for ; Tue, 3 Jan 2012 17:22:42 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53A11E8088 for ; Tue, 3 Jan 2012 17:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1127; q=dns/txt; s=iport; t=1325640162; x=1326849762; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=DkrdnxYoGki4ilbgFhD9RtCH98/jEd6PE0ZzdVCdv2M=; b=k463GWrrPW97XtlJ9Y7PnYw/uoFS/mm66rp3o0HpYhfhbRUNE07L5B52 XC52TNaZssoRh6OoUrJeTJtT2UwoCvKzARIog6bzDqsPGr4IqVRpV/n4K SrUFMbdXTKLxRa4NT4p2rNPqZXl8cmz+01Jb+ycXagCsOFz/AIRVt044k k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAB6pA0+rRDoI/2dsb2JhbABDggWcBo5XgQWBcgEBAQMBCAoBFxA/DAEDAgkPAgQBAQEnBxkjCgkIAQEEEwsXh1gIlzoBnhqMDwSIN4R5AZom X-IronPort-AV: E=Sophos;i="4.71,453,1320624000"; d="scan'208";a="23614108" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 04 Jan 2012 01:22:42 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q041MgH3027659; Wed, 4 Jan 2012 01:22:42 GMT From: "Dan Wing" To: "'Doug Barton'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F036C3B.5030403@dougbarton.us> In-Reply-To: <4F036C3B.5030403@dougbarton.us> Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 17:22:39 -0800 Message-ID: <031701ccca7f$5ade7ed0$109b7c70$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczKWp+TBhQU0kWtQcufg8ha2x10EgAJG1+A Content-Language: en-us Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 01:22:44 -0000 > -----Original Message----- > From: Doug Barton [mailto:dougb@dougbarton.us] > Sent: Tuesday, January 03, 2012 1:00 PM > To: Dan Wing > Cc: 'Fernando Gont'; ipv6@ietf.org; 'Brian E Carpenter' > Subject: Re: Fragmentation-related security issues > > On 01/03/2012 11:02, Dan Wing wrote: > > If IPv6 hosts don't handle > > ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators > > won't work with sub-1280 MTU IPv4 paths. > > ... and this is not a feature because? And no, don't quote the > robustness principle. The floor for MTU has been hard-coded since day > 1, so anyone who breaks that deserves what they get. Yes, I agree, the last paragraph of http://tools.ietf.org/html/rfc2460#section-5 has been around a long time, and IPv6 hosts should follow it. If there is consensus otherwise, we (the collective "we") need to acknowledge what that breaks. -d > > > Doug > > -- > > You can observe a lot just by watching. -- Yogi Berra > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ From dwing@cisco.com Tue Jan 3 17:23:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB90B11E80A0 for ; Tue, 3 Jan 2012 17:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4SSD3-E1qfk for ; Tue, 3 Jan 2012 17:23:45 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 566DD11E8088 for ; Tue, 3 Jan 2012 17:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1354; q=dns/txt; s=iport; t=1325640225; x=1326849825; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=iQFIpgBdm8dHw/iFJEYViIcOXTK5jeHpO4Iu5frbziY=; b=RnKBCo0KFxvp3VquaO54kar80AtdUhb0UPi32iPiiMXubJg1FIUknmZu HjYg/M2O1rPKiUbBM5+Rk7ZKqAV80f2SguM6SsorMfuoYO6eJRM4Er88G QuLkl9BMRSM7pZAbE7Y4h94sqtGY012edmX5XGIRq45YV0b6kVKjDWffW g=; X-IronPort-AV: E=Sophos;i="4.71,453,1320624000"; d="scan'208";a="21972150" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 Jan 2012 01:23:45 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q041NjKQ027995; Wed, 4 Jan 2012 01:23:45 GMT From: "Dan Wing" To: "'Eric Vyncke \(evyncke\)'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar><002f01ccc9a2$9fab9990$df02ccb0$@com><4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> In-Reply-To: <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 17:23:42 -0800 Message-ID: <031801ccca7f$8063c020$812b4060$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczJpZJoGNNTZdAKS0CFzlYHx9huAAAjEW6gAAvmxDAAB3m7YA== Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 01:23:45 -0000 > -----Original Message----- > From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] > Sent: Tuesday, January 03, 2012 1:53 PM > To: Dan Wing (dwing) > Cc: ipv6@ietf.org > Subject: RE: Fragmentation-related security issues > > > -----Original Message----- > > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of Dan > > Wing (dwing) > > > So, I don't think we can just wish away packet-too-big < 1280. > > Rather than dropping those ICMP PTB, let's accept them but let the OS > decide which is the minimum size path MTU that it can > accept/tolerate... > - For a server, this min path MTU should be large (to avoid DoS) > - For a host, this min path MTU could be small > > Of course, if the path is symmetric, the path MTU will be the same on > both direction (assuming everything is well configured). > > OTOH, as written by Jared, let's fail it hard so it is noticeable by > the user is another technique... but with a dual-stack and happy eye- > ball, the end-user will notice nothing and will stay happy with IPv4. Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, and I think also as implemented by Apple, will _not_ fail nicely on Path MTU Discovery problems. It will only fail nicely if connectivity fails (that is, unable to establish the TCP connection). -d From jared@puck.nether.net Tue Jan 3 18:18:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E8011E808A for ; Tue, 3 Jan 2012 18:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE8UkuPH2cyr for ; Tue, 3 Jan 2012 18:18:16 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 935B111E8071 for ; Tue, 3 Jan 2012 18:18:15 -0800 (PST) Received: from [10.50.200.53] (mobile-166-147-117-226.mycingular.net [166.147.117.226]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q042HKQ4017866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 21:17:27 -0500 References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> <031801ccca7f$8063c020$812b4060$@com> In-Reply-To: <031801ccca7f$8063c020$812b4060$@com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Jared Mauch Subject: Re: Fragmentation-related security issues Date: Tue, 3 Jan 2012 21:15:10 -0500 To: Dan Wing X-Mailer: iPhone Mail (9A405) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jan 2012 21:17:28 -0500 (EST) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 02:18:17 -0000 Broken and misconfigured network elements will always exist. We needn't crea= te solutions for everyone's problems that should be addressed otherwise.=20 Jared Mauch On Jan 3, 2012, at 8:23 PM, "Dan Wing" wrote: >> -----Original Message----- >> From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] >> Sent: Tuesday, January 03, 2012 1:53 PM >> To: Dan Wing (dwing) >> Cc: ipv6@ietf.org >> Subject: RE: Fragmentation-related security issues >>=20 >>> -----Original Message----- >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf >> Of Dan >>> Wing (dwing) >>=20 >>> So, I don't think we can just wish away packet-too-big < 1280. >>=20 >> Rather than dropping those ICMP PTB, let's accept them but let the OS >> decide which is the minimum size path MTU that it can >> accept/tolerate... >> - For a server, this min path MTU should be large (to avoid DoS) >> - For a host, this min path MTU could be small >>=20 >> Of course, if the path is symmetric, the path MTU will be the same on >> both direction (assuming everything is well configured). >>=20 >> OTOH, as written by Jared, let's fail it hard so it is noticeable by >> the user is another technique... but with a dual-stack and happy eye- >> ball, the end-user will notice nothing and will stay happy with IPv4. >=20 > Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, > and I think also as implemented by Apple, will _not_ fail nicely > on Path MTU Discovery problems. It will only fail nicely if=20 > connectivity fails (that is, unable to establish the TCP=20 > connection). >=20 > -d >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Tue Jan 3 18:23:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6171C21F84C1 for ; Tue, 3 Jan 2012 18:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.189 X-Spam-Level: X-Spam-Status: No, score=-103.189 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrmR23-S1gZ5 for ; Tue, 3 Jan 2012 18:23:31 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC10621F846B for ; Tue, 3 Jan 2012 18:23:31 -0800 (PST) Received: by yenm7 with SMTP id m7so10331304yen.31 for ; Tue, 03 Jan 2012 18:23:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=afy6NG/duMU7eIR/BCc9CRyV8DwURhQN2p/GjMNpaU0=; b=hDNY+O6jNnlkt2N12c/GEw1A1py1HQOupxbKrKhyISDsH6l8McI7tRKSDFeAKlWyJb jBwInDOhhtyBnn2xz/mg4vZMqovOvs6CbDln4joGpuwiU8Ahca8Sz1pDA1R4gXK2plxW Rhciu93xyabgnOW2FmFpbs+caUr1sMRu+LsBQ= Received: by 10.236.145.234 with SMTP id p70mr35450583yhj.88.1325643809534; Tue, 03 Jan 2012 18:23:29 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id j11sm71231598anl.8.2012.01.03.18.23.27 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 18:23:28 -0800 (PST) Message-ID: <4F03B818.6000100@gmail.com> Date: Wed, 04 Jan 2012 15:23:20 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 02:23:32 -0000 Representing IPv6 Zone Identifiers in Uniform Resource Identifiers We'd like feedback on this. In particular, which of the two options proposed do people prefer? OPTION 1: The existing syntax of IPv6address is extended by adding a specific option for the case of link-local addresses. OPTION 2: The existing syntax of IPv6address is retained, and a zone identifier may be added optionally to any literal address. This allows flexibility for unknown future uses. - Brian & Bob -------- Original Message -------- Subject: I-D Action: draft-carpenter-6man-uri-zoneid-00.txt Date: Tue, 06 Dec 2011 17:27:00 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers Author(s) : Brian Carpenter Robert M. Hinden Filename : draft-carpenter-6man-uri-zoneid-00.txt Pages : 6 Date : 2011-12-06 This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-00.txt From kauer@biplane.com.au Tue Jan 3 19:34:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01F921F84E1 for ; Tue, 3 Jan 2012 19:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBYJiOvtE8E7 for ; Tue, 3 Jan 2012 19:34:09 -0800 (PST) Received: from syd-srv03.ezyreg.com (syd-srv03.ezyreg.com [117.58.251.4]) by ietfa.amsl.com (Postfix) with ESMTP id D725E21F84D4 for ; Tue, 3 Jan 2012 19:34:07 -0800 (PST) Received: from eth4284.nsw.adsl.internode.on.net ([150.101.127.187] helo=[192.168.1.202]) by syd-srv03.ezyreg.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RiHc1-0005e5-Vn for ipv6@ietf.org; Tue, 03 Jan 2012 22:34:02 -0500 Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt From: Karl Auer To: ipv6@ietf.org In-Reply-To: <4F03B818.6000100@gmail.com> References: <4F03B818.6000100@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 04 Jan 2012 14:33:54 +1100 Message-ID: <1325648034.2556.154.camel@karl> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - syd-srv03.ezyreg.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - biplane.com.au X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 03:34:09 -0000 On Wed, 2012-01-04 at 15:23 +1300, Brian E Carpenter wrote: > We'd like feedback on this. In particular, which of the two options > proposed do people prefer? For what my opinion is worth, the second option seems better to me: > OPTION 2: > > The existing syntax of IPv6address is retained, and a zone > identifier may be added optionally to any literal address. > This allows flexibility for unknown future uses. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@biplane.com.au) http://www.biplane.com.au/kauer GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 From dwing@cisco.com Tue Jan 3 21:27:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4C121F85B5 for ; Tue, 3 Jan 2012 21:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzsKumDtZo27 for ; Tue, 3 Jan 2012 21:27:07 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A758D21F84FE for ; Tue, 3 Jan 2012 21:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2369; q=dns/txt; s=iport; t=1325654827; x=1326864427; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=zK1yL2XgNovgHR7bKQAB9TndQ/jDV/jv/eXLCiHW7PM=; b=CHKDeELTTDEvFYSTj3xvbFrsLncDGVQT/VTJMNsf8nR19eW211yusbf9 k5UlsCsLUh4gR0ADk9Y9Oc/mNkiNFJCMnpVogj0CZQM2JQ1z/E6JWfGJk 6QPD9oOQAxoW29Xt0EUd0+wNwEtzIV4J6VlmP9kdRKbqM8OJRG79eBrgr s=; X-IronPort-AV: E=Sophos;i="4.71,454,1320624000"; d="scan'208";a="23633987" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 04 Jan 2012 05:27:07 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q045R7u6018503; Wed, 4 Jan 2012 05:27:07 GMT From: "Dan Wing" To: "'Jared Mauch'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> <031801ccca7f$8063c020$812b4060$@com> In-Reply-To: Subject: RE: Fragmentation-related security issues Date: Tue, 3 Jan 2012 21:27:05 -0800 Message-ID: <035501cccaa1$800be3b0$8023ab10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczKhxw8a/GI0jlWTSC1NA9fo5bM1gAGkBeg Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 05:27:09 -0000 > -----Original Message----- > From: Jared Mauch [mailto:jared@puck.nether.net] > Sent: Tuesday, January 03, 2012 6:15 PM > To: Dan Wing > Cc: Eric Vyncke (evyncke); ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > Broken and misconfigured network elements will always exist. We needn't > create solutions for everyone's problems that should be addressed > otherwise. Ok. So what of the IPv6/IPv4 translators which are placed in front of existing, operational IPv4 networks. -d > Jared Mauch > > On Jan 3, 2012, at 8:23 PM, "Dan Wing" wrote: > > >> -----Original Message----- > >> From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] > >> Sent: Tuesday, January 03, 2012 1:53 PM > >> To: Dan Wing (dwing) > >> Cc: ipv6@ietf.org > >> Subject: RE: Fragmentation-related security issues > >> > >>> -----Original Message----- > >>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf > >> Of Dan > >>> Wing (dwing) > >> > >>> So, I don't think we can just wish away packet-too-big < 1280. > >> > >> Rather than dropping those ICMP PTB, let's accept them but let the > OS > >> decide which is the minimum size path MTU that it can > >> accept/tolerate... > >> - For a server, this min path MTU should be large (to avoid DoS) > >> - For a host, this min path MTU could be small > >> > >> Of course, if the path is symmetric, the path MTU will be the same > on > >> both direction (assuming everything is well configured). > >> > >> OTOH, as written by Jared, let's fail it hard so it is noticeable by > >> the user is another technique... but with a dual-stack and happy > eye- > >> ball, the end-user will notice nothing and will stay happy with > IPv4. > > > > Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, > > and I think also as implemented by Apple, will _not_ fail nicely > > on Path MTU Discovery problems. It will only fail nicely if > > connectivity fails (that is, unable to establish the TCP > > connection). > > > > -d > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From fweimer@bfk.de Wed Jan 4 00:20:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E872621F86B9 for ; Wed, 4 Jan 2012 00:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZBbM6RXkgbA for ; Wed, 4 Jan 2012 00:20:01 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id A1A4E21F86BE for ; Wed, 4 Jan 2012 00:20:00 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RiM4k-0000c2-D7; Wed, 04 Jan 2012 08:19:58 +0000 Received: by bfk.de with local id 1RiM4k-00024d-8l; Wed, 04 Jan 2012 08:19:58 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> Date: Wed, 04 Jan 2012 08:19:58 +0000 In-Reply-To: <4F028C9B.4010704@si6networks.com> (Fernando Gont's message of "Tue, 03 Jan 2012 02:05:31 -0300") Message-ID: <82ehvfnakx.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:20:02 -0000 * Fernando Gont: > Why should you drop in this case, when it's trivial to process these > fragments safely, with no side effects?? Do we really know that adding a fragment header to all outgoing packets does not cause them to be rejected? Could this be deployed at large DNS servers in a risk-free fashion, for instance? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mohacsi@niif.hu Wed Jan 4 00:28:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2078121F86C8 for ; Wed, 4 Jan 2012 00:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFuBnpO4mxO8 for ; Wed, 4 Jan 2012 00:28:39 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEED21F8613 for ; Wed, 4 Jan 2012 00:28:38 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id EFC7C878A3; Wed, 4 Jan 2012 09:28:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id ziuYzhJqBdHG; Wed, 4 Jan 2012 09:28:33 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id CB363878A2; Wed, 4 Jan 2012 09:28:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id C4EBD877BE; Wed, 4 Jan 2012 09:28:33 +0100 (CET) Date: Wed, 4 Jan 2012 09:28:33 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Fernando Gont Subject: Re: Atomic fragments: converging on something? In-Reply-To: <4F038BD2.6080805@si6networks.com> Message-ID: References: <4F038BD2.6080805@si6networks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 08:28:40 -0000 On Tue, 3 Jan 2012, Fernando Gont wrote: > Folks, > > The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered > some (unintended) discussion about the usefulness/legitimacy of IPv6 > "atomic fragments" (IPv6 packets that contain a Fragmentation Header, > but that have the "More Fragments" bit set to zero). > > My understanding is that is quite clear that such packets have been > found in the wild and that a number of things would break if they were > blocked or banned. > > That said, I'd like some feedback on the actual proposal in > draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned > "atomic fragments" as if they were non-fragmented packets. This would > basically eliminate all the security issues and problems normally > associated with framgentation, while still allowing their legitimate use. I support your proposal. I will do a more thorough review of your draft. Best Regards, Janos Mohacsi > > Thoughts? > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From rja.lists@gmail.com Wed Jan 4 03:36:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FBD21F852C for ; Wed, 4 Jan 2012 03:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.643 X-Spam-Level: X-Spam-Status: No, score=-3.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g87O6vXtC1lv for ; Wed, 4 Jan 2012 03:36:25 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9AD21F851D for ; Wed, 4 Jan 2012 03:36:25 -0800 (PST) Received: by qcsf15 with SMTP id f15so12270776qcs.31 for ; Wed, 04 Jan 2012 03:36:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=K7tJSkcqLj0V0MuFHZJ/BJzxoRkoYBRq7LUpthq9s5A=; b=nSy6RKASKKIeQqPOVrAiuZUqpaRzkfoJ2eJDfqaoKhsZI+CsYOd9l+YZEhTtzLLuBp vrcXB/R9B/xtqus/v2FKwl3KDfqx8APtTZ18oKDBOyAAUhiC4yAAqQ1FRE18DjoNLJDV TILol2fF6NlSj6/nzwtD84lXvZ2TNPjPFQF/I= Received: by 10.229.75.141 with SMTP id y13mr19985499qcj.135.1325676984823; Wed, 04 Jan 2012 03:36:24 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id ev2sm58156191qab.15.2012.01.04.03.36.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 03:36:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Fragmentation-related security issues From: RJ Atkinson In-Reply-To: Date: Wed, 4 Jan 2012 06:36:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:36:26 -0000 On 03 Jan 2012, at 17:57 , Philip Homburg wrote: > - For IPv6, given that the host has to do the fragmentation, > a big minimum MTU is required. Otherwise, too much stuff > will end up being fragmented at 576. There is no evidence for the claim above. When the minimum=20 Link MTU for IPv6 *was* set to 576, that did not happen. Instead, most traffic was Ethernet MTU without fragmentation, and the next most common packet size was (Ethernet MTU - overhead for DSL encapsulation/tunnelling). Packets at 576 were seen -- but very very infrequently -- so they were NOT a particular burden on the end systems. > My guess is, that anybody who is running a links at less > than 1280 is just going to get a lot of trouble. That applies > both to the links you mentioned and any IPv6-to-IPv4 translators. Clearly it is more complex to run an IPv6 link below 1280 today than it was when IPv6 specifications supported a 576 byte MTU. Folks with such links tell me that it mostly works today. IPv6-IPv4 translators aren't going away. There are lots of other reasons they get deployed -- including transition and interoperability. > Most IPv4 links are bigger than 1280. So, those translators will seem = to work > in most cases. IPv4 links smaller than 1280 will just see failures = that > are quite hard to debug. Actually, IPv4 links with 576 byte MTUs aren't problematic. They have worked well for ~30 years now. RF links aren't going away, and they aren't all being replaced by IEEE 802.11 or IEEE 802.16 either.=20 Cheers, Ran From pch-b29AA871B@u-1.phicoh.com Wed Jan 4 04:17:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81BE21F85E4 for ; Wed, 4 Jan 2012 04:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_WORKS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9H6mPB173S8 for ; Wed, 4 Jan 2012 04:17:33 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 50D6321F8600 for ; Wed, 4 Jan 2012 04:17:33 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RiPma-0001YlC; Wed, 4 Jan 2012 13:17:28 +0100 Message-Id: To: RJ Atkinson Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> In-reply-to: Your message of "Wed, 4 Jan 2012 06:36:25 -0500 ." <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> Date: Wed, 04 Jan 2012 13:17:22 +0100 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:17:34 -0000 In your letter dated Wed, 4 Jan 2012 06:36:25 -0500 you wrote: > >On 03 Jan 2012, at 17:57 , Philip Homburg wrote: >> - For IPv6, given that the host has to do the fragmentation, >> a big minimum MTU is required. Otherwise, too much stuff >> will end up being fragmented at 576. > >There is no evidence for the claim above. When the minimum >Link MTU for IPv6 *was* set to 576, that did not happen. RFC-2460 is from 1998. You are talking about the IPv6 network before 1998? And that resembles todays IPv6 internet in what way? >Instead, most traffic was Ethernet MTU without fragmentation, >and the next most common packet size was (Ethernet MTU - >overhead for DSL encapsulation/tunnelling). Packets at >576 were seen -- but very very infrequently -- so they >were NOT a particular burden on the end systems. Except that DNS(SEC) packets will be fragmented at the mimimum MTU (see for example the discussion in http://tools.ietf.org/html/draft-andrews-dnsext-udp-fragmentation-00) Setting the minimum MTU to 576 has to potential to cause of damage to DNSSEC. >> My guess is, that anybody who is running a links at less >> than 1280 is just going to get a lot of trouble. That applies >> both to the links you mentioned and any IPv6-to-IPv4 translators. > >Clearly it is more complex to run an IPv6 link below 1280 today >than it was when IPv6 specifications supported a 576 byte MTU. >Folks with such links tell me that it mostly works today. That's the problem with PMTU in general: it mostly works. >IPv6-IPv4 translators aren't going away. There are lots >of other reasons they get deployed -- including transition >and interoperability. Most IPv4 links are bigger than 1280. Those that aren't will cause suffering. >> Most IPv4 links are bigger than 1280. So, those translators will seem to wor >k >> in most cases. IPv4 links smaller than 1280 will just see failures that >> are quite hard to debug. > >Actually, IPv4 links with 576 byte MTUs aren't problematic. >They have worked well for ~30 years now. Except when they do. When I set the link MTU of my WAN link link to 576, VoIP stops working (over IPv4). I could either try to track down a technical person to get them to fix the problem, or I just raise the MTU. And that's how it goes in lots of cases. >RF links aren't going away, and they aren't all being >replaced by IEEE 802.11 or IEEE 802.16 either. They have had since 1998 to find a fix for the 1280 mimimum MTU problem. It is not my problem. From jared@puck.nether.net Wed Jan 4 04:23:07 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AA921F85FE for ; Wed, 4 Jan 2012 04:23:07 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHQtYEbZeQgp for ; Wed, 4 Jan 2012 04:23:06 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id A1A6B21F85BA for ; Wed, 4 Jan 2012 04:22:54 -0800 (PST) Received: from [172.17.91.138] ([12.238.77.194]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q04CMB1F009158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jan 2012 07:22:11 -0500 Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <035501cccaa1$800be3b0$8023ab10$@com> Date: Wed, 4 Jan 2012 07:23:03 -0500 Content-Transfer-Encoding: 7bit Message-Id: <898BAAF2-39D6-44A2-BB07-7794D48B70E1@puck.nether.net> References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> <031801ccca7f$8063c020$812b4060$@com> <035501cccaa1$800be3b0$8023ab10$@com> To: "Dan Wing" X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Wed, 04 Jan 2012 07:22:12 -0500 (EST) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 12:23:07 -0000 On Jan 4, 2012, at 12:27 AM, Dan Wing wrote: >> -----Original Message----- >> From: Jared Mauch [mailto:jared@puck.nether.net] >> Sent: Tuesday, January 03, 2012 6:15 PM >> To: Dan Wing >> Cc: Eric Vyncke (evyncke); ipv6@ietf.org >> Subject: Re: Fragmentation-related security issues >> >> Broken and misconfigured network elements will always exist. We needn't >> create solutions for everyone's problems that should be addressed >> otherwise. > > Ok. So what of the IPv6/IPv4 translators which are placed in front > of existing, operational IPv4 networks. If the translator can't talk at some larger MSS, it can reduce that, one does this on cisco with 'ip tcp adjust-mss' on the interface for TCP. I assume nobody forgot to create a comparable command for ipv6 :) For UDP, there are silent drops/blackholes today. Translation technologies are a bandaid and expected to have tradeoffs. This will be one of them that may make going native more attractive. Expecting the ICMP messages that may be dropped already to be propagated and translated properly isn't ideal, but this is something that doesn't need lots of attention. - Jared > > -d > > >> Jared Mauch >> >> On Jan 3, 2012, at 8:23 PM, "Dan Wing" wrote: >> >>>> -----Original Message----- >>>> From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] >>>> Sent: Tuesday, January 03, 2012 1:53 PM >>>> To: Dan Wing (dwing) >>>> Cc: ipv6@ietf.org >>>> Subject: RE: Fragmentation-related security issues >>>> >>>>> -----Original Message----- >>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On >> Behalf >>>> Of Dan >>>>> Wing (dwing) >>>> >>>>> So, I don't think we can just wish away packet-too-big < 1280. >>>> >>>> Rather than dropping those ICMP PTB, let's accept them but let the >> OS >>>> decide which is the minimum size path MTU that it can >>>> accept/tolerate... >>>> - For a server, this min path MTU should be large (to avoid DoS) >>>> - For a host, this min path MTU could be small >>>> >>>> Of course, if the path is symmetric, the path MTU will be the same >> on >>>> both direction (assuming everything is well configured). >>>> >>>> OTOH, as written by Jared, let's fail it hard so it is noticeable by >>>> the user is another technique... but with a dual-stack and happy >> eye- >>>> ball, the end-user will notice nothing and will stay happy with >> IPv4. >>> >>> Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, >>> and I think also as implemented by Apple, will _not_ fail nicely >>> on Path MTU Discovery problems. It will only fail nicely if >>> connectivity fails (that is, unable to establish the TCP >>> connection). >>> >>> -d >>> >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- From rja.lists@gmail.com Wed Jan 4 05:46:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8942A21F8746 for ; Wed, 4 Jan 2012 05:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.638 X-Spam-Level: X-Spam-Status: No, score=-3.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnXS1qcIjkNs for ; Wed, 4 Jan 2012 05:46:37 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EFE1321F8537 for ; Wed, 4 Jan 2012 05:46:36 -0800 (PST) Received: by qadz3 with SMTP id z3so11214618qad.10 for ; Wed, 04 Jan 2012 05:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=1DaxkVoK8kqsDpxeIfAQ28+n8G8IiDgbLjp1A2Kuk4g=; b=phsZFGuRIjuenUv+/A/4FIe7Uvk8xi6V01M9yAzEFfptr7eY4sgm8uNYDL9E1njAUU T8n/c+7DfOCrZR5HxLb0la2mFkyh9U/YF1wtWbJ0MG/Xa7A+7jrQgsllxtG1qPnjhMpK VzB2NK3cYuiW0XG6eykLpyH1IyiHZ5QFCcr0w= Received: by 10.224.31.148 with SMTP id y20mr66212483qac.80.1325684794112; Wed, 04 Jan 2012 05:46:34 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id hv20sm106878711qab.22.2012.01.04.05.46.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 05:46:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Fragmentation-related security issues From: RJ Atkinson In-Reply-To: Date: Wed, 4 Jan 2012 08:46:31 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:46:37 -0000 On 04 Jan 2012, at 07:17 , Philip Homburg wrote: > RFC-2460 is from 1998. You are talking about the IPv6 network > before 1998? And that resembles todays IPv6 internet in what way? The network layer is largely the same. Routing is largely the same, except that table sizes always seem to increase. Certainly transport protocols are largely the same. We now have SCTP, although it seems not yet widely deployed. I very much hope DNSsec will become much more widely deployed. I have spent a fair amount of energy over the past ~15 years helping to ensure that [other folks'] DNSsec-related R&D would be funded. The bulk of the Internet continues to use IPv4 today, and probably will for the next decade. The IPv4 specifications and widely deployed IPv4 implementations both support a 576 byte Link MTU. So DNSsec will need to work over 576 byte links just to be deployable in the bulk of the deployed Internet. That might be awkward, or sub-optimal, but it is not a recent development. > When I set the link MTU of my WAN link to 576, > VoIP stops working (over IPv4). Curious. I know of several deployments of VoIP over small MTU links. They work fine using standard off-the-shelf IETF protocols for VoIP (e.g. SIP, RTP). So it isn't a protocol problem. > They have had since 1998 to find a fix for the > 1280 mimimum MTU problem. It is not my problem. The Link MTU minimum size is the IETF's problem, because the IETF is trying to support the whole globe's networking needs. IPv4 does so today. It would be sad if IPv6 could not do so. Cheers, Ran From rja.lists@gmail.com Wed Jan 4 05:55:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A230C21F85C4 for ; Wed, 4 Jan 2012 05:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06MJzYe-lhuA for ; Wed, 4 Jan 2012 05:55:15 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C321F85C1 for ; Wed, 4 Jan 2012 05:55:15 -0800 (PST) Received: by qadz3 with SMTP id z3so11220853qad.10 for ; Wed, 04 Jan 2012 05:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=1kgr9sBy+ZtG+bm8OGHhBDSEVdEnn9dxIu7T7zckDfo=; b=e9TMlbEVdeq02cSlv/tbbcNwlm8xKmO9YGV7hwlTbP8Nn50a3Vw8/Lm0ZO8olq6Ewn xWB8om7x3W9RuSMOJg/+inCDEie61NAeMFU1xNA0hMHlYV4csWfYv3G9LaRM6ujZH2oF 8P1yQ6yoCAmMC+7SSKPhQ0zsWg26/mF58cyIU= Received: by 10.224.215.5 with SMTP id hc5mr5395152qab.20.1325685315228; Wed, 04 Jan 2012 05:55:15 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id m20sm106943644qaj.14.2012.01.04.05.55.14 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 05:55:14 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Fragmentation-related security issues Date: Wed, 4 Jan 2012 08:55:13 -0500 Message-Id: <92CD3301-2BCA-43A5-8C08-97AC0F8E6B6B@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:55:16 -0000 Earlier, Doug Barton wrote: > On 01/03/2012 11:02, Dan Wing wrote: > > If IPv6 hosts don't handle > > ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators > > won't work with sub-1280 MTU IPv4 paths. > > ... and this is not a feature because? And no, don't quote the > robustness principle. The floor for MTU has been hard-coded since day 1, > so anyone who breaks that deserves what they get. In fact, the MTU floor CHANGED from 576 to 1280 well AFTER day 1, as I noted in a separate note within the past day or so. (If it had not changed, then I likely would not have posted any notes in the past few days.) Separately, I'm old enough to believe in the robustness principle -- because Jon Postel's argument for it was (and remains) quite correct. Cheers, Ran From rja.lists@gmail.com Wed Jan 4 05:57:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077B921F8705 for ; Wed, 4 Jan 2012 05:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TA3mYUOyM2mw for ; Wed, 4 Jan 2012 05:57:14 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3A22B21F86E5 for ; Wed, 4 Jan 2012 05:57:14 -0800 (PST) Received: by qcsf15 with SMTP id f15so12348084qcs.31 for ; Wed, 04 Jan 2012 05:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=kQeZZHvDyKXQfSnLxVFfgfgJj2CFx1HclmGxAxW0h6Q=; b=uJjErK+H2wmSoz2FZ9e3FsejHr1AVl8FXeg5g36l1lQiqCOAWhx12BVeC2BcRLh70E iOULtCEMUw/teAgHhqXbi+C4CuuysIicDH7FJCAF3BD5+pAZw187NmdRfxBa0YFwwa7Z ELpbgkuZaoNLuPQqMQfJ7nJ5F9FstDgVVsu40= Received: by 10.224.1.136 with SMTP id 8mr67186115qaf.54.1325685433750; Wed, 04 Jan 2012 05:57:13 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id v5sm34851077qao.21.2012.01.04.05.57.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 05:57:12 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Fragmentation-related security issues Date: Wed, 4 Jan 2012 08:57:11 -0500 Message-Id: To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:57:15 -0000 Earlier, Mark Andrews wrote: > Atomic fragments > 1280 should not appear in the network. > Atomic fragments <= 1280 are a expected part of the IPv6 landscape. > For TCP they should be rare. > For UDP it depends on the protocol running on top of UDP. > PMTUD relying on PTB is just not reliable. To the best of my understanding, the above is correct. Cheers, Ran From pch-b29AA871B@u-1.phicoh.com Wed Jan 4 07:25:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFA821F8767 for ; Wed, 4 Jan 2012 07:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.216 X-Spam-Level: X-Spam-Status: No, score=-8.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5SeKk0UZ1FY for ; Wed, 4 Jan 2012 07:25:16 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6768721F875F for ; Wed, 4 Jan 2012 07:25:15 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RiSiB-0001ZKC; Wed, 4 Jan 2012 16:25:07 +0100 Message-Id: To: RJ Atkinson Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> In-reply-to: Your message of "Wed, 4 Jan 2012 08:46:31 -0500 ." Date: Wed, 04 Jan 2012 16:24:57 +0100 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 15:25:16 -0000 In your letter dated Wed, 4 Jan 2012 08:46:31 -0500 you wrote: >On 04 Jan 2012, at 07:17 , Philip Homburg wrote: >> RFC-2460 is from 1998. You are talking about the IPv6 network >> before 1998? And that resembles todays IPv6 internet in what way? > >The network layer is largely the same. Routing >is largely the same, except that table sizes >always seem to increase. Certainly transport >protocols are largely the same. We now have SCTP, >although it seems not yet widely deployed. Yes, but PMTU failures are not a protocol issue. Is it is an operational issue. So when the IPv6 network is just a bunch of techies who are connected by tunnels, you expect PMTU to sort of work. By the time the internet is big is enough that some routers just send ICMPs with link local source and nobody notices, then PMTU starts to break down. >The bulk of the Internet continues to use IPv4 today, >and probably will for the next decade. The IPv4 >specifications and widely deployed IPv4 >implementations both support a 576 byte Link MTU. > >So DNSsec will need to work over 576 byte links >just to be deployable in the bulk of the deployed >Internet. That might be awkward, or sub-optimal, >but it is not a recent development. I'm sure you know about the small difference between IPv4 and IPv6 when it comes to fragmentation. For IPv4, if a DNS server need to send a, say, 1000 octet reply then it can just send it. If necessary, routers on the way will fragment the reply. Your 576 octet link will have no effect on me. On the other hand, for IPv6, a DNS server will have to fragment at the lowest common denominator. So making the minimum link MTU 576, will cause a lot more IPv6 fragments then you would get for IPv4. And makes IPv6 quite a bit worse than IPv4. If you follow this to the logical conclusion, then with the IPv6-IPv4 translators, a DNS server has to add a fragmentation header to every DNS reply, even the small ones. Wasting an enormous amount of processing power in the years to come. >> When I set the link MTU of my WAN link to 576, >> VoIP stops working (over IPv4). > >Curious. I know of several deployments of VoIP >over small MTU links. They work fine using standard >off-the-shelf IETF protocols for VoIP (e.g. SIP, RTP). >So it isn't a protocol problem. It is not a protocol problem. My guess is that this is some kind of firewall that drops fragmented packets. But can't be sure. >> They have had since 1998 to find a fix for the >> 1280 mimimum MTU problem. It is not my problem. > >The Link MTU minimum size is the IETF's problem, >because the IETF is trying to support the whole >globe's networking needs. IPv4 does so today. >It would be sad if IPv6 could not do so. Well, you can always tunnel IPv6 over IPv4. Problem solved :-) From dwing@cisco.com Wed Jan 4 08:14:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2416A21F8799 for ; Wed, 4 Jan 2012 08:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfTNy0N7OfDj for ; Wed, 4 Jan 2012 08:14:42 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8B21921F8787 for ; Wed, 4 Jan 2012 08:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2963; q=dns/txt; s=iport; t=1325693682; x=1326903282; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=PBMPUznpdZDyj25duYNuli3DIGrkIxIDSnNp6yYW9j8=; b=UrsuSmIr99mDaD2OcylixJLP3PoX6T5Y1CSvJ7p0B5lwFBBdwHyPStK6 nHttbnctKenbdgGqtRdwlIwLdjlxh2o4GtCpZ09F28f3IU/G86q06MR1U P40974ejF3s3vc11iYPj1pbds+S4UjF6Ao63rbCELYPGt4vfVoNjQXejM E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFABR6BE+rRDoI/2dsb2JhbABDggWcCY5ZgQWBcgEBAQQBAQEFCgEXPgYLDAEDAgkPAgQBAQEnBxkIBhUKCQgBAQQTCxeHYJc5AZ4jBIwPBIgFM4R5AZJBh2Y X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; d="scan'208";a="23790031" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 04 Jan 2012 16:14:42 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q04GEgB5016518; Wed, 4 Jan 2012 16:14:42 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> <01f701ccca58$4b7bd040$e27370c0$@com> <4581455F-282E-42E6-B328-CEB06620C844@free.fr> In-Reply-To: <4581455F-282E-42E6-B328-CEB06620C844@free.fr> Subject: RE: Fragmentation-related security issues Date: Wed, 4 Jan 2012 08:14:39 -0800 Message-ID: <043801cccafb$f754beb0$e5fe3c10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczKxWPhjyUkE1yoRqGV+gV2FmRGVgANf/lA Content-Language: en-us Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:14:43 -0000 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Wednesday, January 04, 2012 1:44 AM > To: Dan Wing > Cc: 'Brian E Carpenter'; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > Hi Dan, >=20 > As you rightly reminded, the current specification permits PTB<1280 = for > a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids it > for an IPv6 DST. >=20 > Rather than changing this, what about clarifying that a host SHOULD > treat a received PTB>1280 as: > - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 of > RFC6147) That only helps in half of the RFC6144 scenarios, where the IPv6 host is behind the translator (e.g., "Scenario 1: an IPv6 network to the IPv4 Internet"). It would not help in the other half of the RFC6144 scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4: an IPv4 network to the IPv6 Internet"). It is RFC6144's Scenario 4 where stateless IPv6/IPv4 translators, where the IPv4 network has a small MTU, that there is a reliance on the last paragraph of Section 5 of RFC2460. -d > - an ERROR otherwise. >=20 > This would at least dissuade from tolerating IPv6 paths with PMTU < > 1280. >=20 > RD >=20 >=20 >=20 > Le 2012-01-03 =E0 21:43, Dan Wing a =E9crit : > >> ... > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> ... > >> On 2012-01-04 08:02, Dan Wing wrote: > >>> ... > >>> So, I don't think we can just wish away packet-too-big < 1280. > >> > >> Sadly, that seems to be true unless we make a much more radical > change, > >> because of translators. > > > > Or, we declare a new restriction that translators are not expected = to > > work if the IPv4 network has an MTU less than 1260 (1260=3D1280-20, > > because IPv6 header is 20B bigger than IPv4 header). I don't know = if > there > > is consensus for such a restriction. To date, both RFC2765 and > RFC6145 > > avoided such a restriction. However, if there are widespread IPv6 > > host implementations or firewalls that erroneously filter or ignore > > ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to > > accept that restriction, and modify their IPv4 networks to have > > MTU>=3D1260. Such IPv4 network modifications would add to further > > pain to IPv6 coexistence. MTU research by Ben Stasiewicz and > > Matthew Luckie (WAND), published and presented at RIPE and > > other conferences, shows a 2-3% failure rate to various popular > > web sites. They did additional testing during World IPv6 Day, > > but I haven't dug into those results yet. > > > > -d > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- From dwing@cisco.com Wed Jan 4 08:19:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B69821F8790 for ; Wed, 4 Jan 2012 08:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKlxtguainQd for ; Wed, 4 Jan 2012 08:19:23 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5C09D21F8787 for ; Wed, 4 Jan 2012 08:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3861; q=dns/txt; s=iport; t=1325693963; x=1326903563; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=z/mYOmqYR4Kx/kEZS87wjlHu4oSA4wYK2iWvsZhawDs=; b=Gz/I/wNYEwRnHYiPvkZzO9ttcouRIStN6nSOQYwzsyLBO5WPtvvQFoPO BN1zAmTKM/J68LfawwsuvhRmtmlEYCNHrPpz+tWyCkGtuiY7TgK8z76jA mtqh0xZhYRVwvM4UbQh3SzAJV0ucSzEtGD17ax7m0AOJa8qDRh1NTSe29 s=; X-IronPort-AV: E=Sophos;i="4.71,456,1320624000"; d="scan'208";a="23704283" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 04 Jan 2012 16:19:23 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q04GJNE6011662; Wed, 4 Jan 2012 16:19:23 GMT From: "Dan Wing" To: "'Jared Mauch'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <317616CE96204D49B5A1811098BA89500625BE56@XMB-AMS-110.cisco.com> <031801ccca7f$8063c020$812b4060$@com> <035501cccaa1$800be3b0$8023ab10$@com> <898BAAF2-39D6-44A2-BB07-7794D48B70E1@puck.nether.net> In-Reply-To: <898BAAF2-39D6-44A2-BB07-7794D48B70E1@puck.nether.net> Subject: RE: Fragmentation-related security issues Date: Wed, 4 Jan 2012 08:19:20 -0800 Message-ID: <043d01cccafc$9eca5010$dc5ef030$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczK25tbpZ56iA1/SwiEr60cE/8IrwAIGAwQ Content-Language: en-us Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:19:24 -0000 > -----Original Message----- > From: Jared Mauch [mailto:jared@puck.nether.net] > Sent: Wednesday, January 04, 2012 4:23 AM > To: Dan Wing > Cc: 'Eric Vyncke (evyncke)'; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues > > > On Jan 4, 2012, at 12:27 AM, Dan Wing wrote: > > >> -----Original Message----- > >> From: Jared Mauch [mailto:jared@puck.nether.net] > >> Sent: Tuesday, January 03, 2012 6:15 PM > >> To: Dan Wing > >> Cc: Eric Vyncke (evyncke); ipv6@ietf.org > >> Subject: Re: Fragmentation-related security issues > >> > >> Broken and misconfigured network elements will always exist. We > needn't > >> create solutions for everyone's problems that should be addressed > >> otherwise. > > > > Ok. So what of the IPv6/IPv4 translators which are placed in front > > of existing, operational IPv4 networks. > > If the translator can't talk at some larger MSS, it can reduce that, > one does this on cisco with 'ip tcp adjust-mss' on the interface for > TCP. > I assume nobody forgot to create a comparable command for ipv6 :) We can clamp TCP MSS on our various translator devices. (Oh, Cisco did forget to create a comparable command for IPv6, helpful for tunnels and what-not on IPv4 and IPv6 because ICMP is so often borked or filtered. That oversight is being fixed.) > For UDP, there are silent drops/blackholes today. Translation > technologies > are a bandaid and expected to have tradeoffs. This will be one of them > that may make going native more attractive. Unfortunately a broken network is just that: broken. It does not encourage users to move, just to demand a fix. -d > Expecting the ICMP messages that may be dropped already to be > propagated and > translated properly isn't ideal, but this is something that doesn't > need lots > of attention. > > - Jared > > > > > -d > > > > > >> Jared Mauch > >> > >> On Jan 3, 2012, at 8:23 PM, "Dan Wing" wrote: > >> > >>>> -----Original Message----- > >>>> From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com] > >>>> Sent: Tuesday, January 03, 2012 1:53 PM > >>>> To: Dan Wing (dwing) > >>>> Cc: ipv6@ietf.org > >>>> Subject: RE: Fragmentation-related security issues > >>>> > >>>>> -----Original Message----- > >>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > >> Behalf > >>>> Of Dan > >>>>> Wing (dwing) > >>>> > >>>>> So, I don't think we can just wish away packet-too-big < 1280. > >>>> > >>>> Rather than dropping those ICMP PTB, let's accept them but let the > >> OS > >>>> decide which is the minimum size path MTU that it can > >>>> accept/tolerate... > >>>> - For a server, this min path MTU should be large (to avoid DoS) > >>>> - For a host, this min path MTU could be small > >>>> > >>>> Of course, if the path is symmetric, the path MTU will be the same > >> on > >>>> both direction (assuming everything is well configured). > >>>> > >>>> OTOH, as written by Jared, let's fail it hard so it is noticeable > by > >>>> the user is another technique... but with a dual-stack and happy > >> eye- > >>>> ball, the end-user will notice nothing and will stay happy with > >> IPv4. > >>> > >>> Happy Eyeballs, is spec'd and as implemented by Chrome and Firefox, > >>> and I think also as implemented by Apple, will _not_ fail nicely > >>> on Path MTU Discovery problems. It will only fail nicely if > >>> connectivity fails (that is, unable to establish the TCP > >>> connection). > >>> > >>> -d > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> ------------------------------------------------------------------- > - From brian@innovationslab.net Wed Jan 4 08:28:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1697B21F87CE for ; Wed, 4 Jan 2012 08:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJdkxgLdZJxx for ; Wed, 4 Jan 2012 08:28:44 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC9021F87CB for ; Wed, 4 Jan 2012 08:28:44 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id E6774880F0; Wed, 4 Jan 2012 08:28:43 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9DA1F130002; Wed, 4 Jan 2012 08:28:43 -0800 (PST) Message-ID: <4F047E3A.1040304@innovationslab.net> Date: Wed, 04 Jan 2012 11:28:42 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-lynn-6man-6lobac References: <4E947777.1040507@innovationslab.net> In-Reply-To: <4E947777.1040507@innovationslab.net> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:28:45 -0000 All, Sorry for the delay... The consensus of the WG is to adopt this draft. I will instruct the authors to publish the next version as a 6MAN WG draft. Regards, Brian On 10/11/11 1:05 PM, Brian Haberman wrote: > All, > This is a consensus call on adopting: > > Title : Transmission of IPv6 over MS/TP Networks > Author(s) : Kerry Lynn > Jerry Martocci > Carl Neilson > Stuart Donaldson > Filename : draft-lynn-6man-6lobac-02.txt > Pages : 14 > Date : 2011-10-10 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on October 25, 2011. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Wed Jan 4 09:01:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2052421F878A for ; Wed, 4 Jan 2012 09:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqNuwFfRJ5Gt for ; Wed, 4 Jan 2012 09:01:00 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1884821F8786 for ; Wed, 4 Jan 2012 09:01:00 -0800 (PST) Received: from [209.13.155.122] (helo=[10.42.43.100]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiUCQ-0008Ix-DX; Wed, 04 Jan 2012 18:00:29 +0100 Message-ID: <4F03BC4F.3020801@si6networks.com> Date: Tue, 03 Jan 2012 23:41:19 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <4F028C42.1020702@si6networks.com> <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> In-Reply-To: <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 17:01:01 -0000 Bjoern, On 01/03/2012 09:22 PM, Bjoern A. Zeeb wrote: >>> The idea of having the fragment offset to stay compatible the way things worked >>> in IPv4 certainly was a great idea and has later proven to be a PITA. What I'd >>> really like to have is a silly fragment counter 1..n, so no overlapping possible >>> (and not just not allowed on paper anymore as that does not remove that code >>> to check from the stacks), simple handling of duplicate fragments, and no >>> "atomic frags" allowed. >> >> That makes a bunch of IP fragmentation attacks (mostly DoS) trivial... >> -- we should have learnt the leason from IPv4, shouldn't we? > > More than knowing all the fragment offsets upfront with the first packet > for almost all implementations? Seriously? Who implements packet size > randomizations for fragments to avoid that? Sorry, it seems that the discussion got mixed up. Trying to clear up the mess: *I* am arguing in favor of: a) Fragment ID randomization b) Processing of atomic fragments as non-fragmented traffic. Any arguments against that? >>> Luckily the fragment header still has a lot of spare space that could allow >>> to indicate which scheme is used and dropping a packet unless a bit is set >>> (not being set indicating the old scheme) is really easy to implement, esp. >>> after a transition period and ripping the old code out would be as well then;-) >>> I 'd really not want to add even more complicated house keeping and stuff >>> long term. >> >> You're already in a complicated position as a result of predictable I-Ds >> >> OpenBSD randomized them, > > Yeah and so do other BSDs derived from KAME... > ( http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_output.c#rev1.397 ) But this wasn't the case for Linux (they've now patched, though) or OpenSolaris (partially). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From timothyhartrick@gmail.com Wed Jan 4 09:51:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4473621F87E7 for ; Wed, 4 Jan 2012 09:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLMN6oUVj6La for ; Wed, 4 Jan 2012 09:51:37 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA4821F87CB for ; Wed, 4 Jan 2012 09:51:37 -0800 (PST) Received: by pbdd12 with SMTP id d12so15359106pbd.31 for ; Wed, 04 Jan 2012 09:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QXmaMB+0JXW3UX53hUMOFROLigVChC7k/3vIKtApQ6s=; b=fvchq/j31jOd+Yr7GxHEpMAPgUAy2nt4m5xnkQmrtkgssIaxBNtbtiFnPwLj8BZ7Ak seVb/qe4msD4QLQlDWeekyQ/8ly8YacA21JXAMLNhs77b4hdBfE71U6dzUjLzCGnoKs1 GyOJkwP/2qFtXqoP4vo8JocuwzsNFmhfkMSG8= MIME-Version: 1.0 Received: by 10.68.73.104 with SMTP id k8mr142284270pbv.104.1325699497183; Wed, 04 Jan 2012 09:51:37 -0800 (PST) Received: by 10.68.51.170 with HTTP; Wed, 4 Jan 2012 09:51:37 -0800 (PST) In-Reply-To: <4F038BD2.6080805@si6networks.com> References: <4F038BD2.6080805@si6networks.com> Date: Wed, 4 Jan 2012 09:51:37 -0800 Message-ID: Subject: Re: Atomic fragments: converging on something? From: Timothy Hartrick To: Fernando Gont Content-Type: multipart/alternative; boundary=f46d041706e39bcab104b5b777f7 X-Mailman-Approved-At: Wed, 04 Jan 2012 10:00:53 -0800 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 17:51:40 -0000 --f46d041706e39bcab104b5b777f7 Content-Type: text/plain; charset=ISO-8859-1 Fernando, On Tue, Jan 3, 2012 at 3:14 PM, Fernando Gont wrote: > Folks, > > The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered > some (unintended) discussion about the usefulness/legitimacy of IPv6 > "atomic fragments" (IPv6 packets that contain a Fragmentation Header, > but that have the "More Fragments" bit set to zero). > > Just to clarify what you mean by an atomic fragment; you mean fragments with an offset of 0 and the "More Fragments" flag set to zero. That is, this is the beginning and there is no more. > My understanding is that is quite clear that such packets have been > found in the wild and that a number of things would break if they were > blocked or banned. > > They are essential to translation systems. Firewalls that block them are broken since "atomic fragments" represent no security risk and are a legal part of the protocol. > That said, I'd like some feedback on the actual proposal in > draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned > "atomic fragments" as if they were non-fragmented packets. This would > basically eliminate all the security issues and problems normally > associated with framgentation, while still allowing their legitimate use. > > On the one hand I would prefer that this document not be necessary. That is, treating "atomic fragments" as not being fragmented at all is the way that any competent software engineer would treat them. The idea of allocating reassembly state and timers for datagrams of this sort and then executing anything like the normal reassembly logic on them is absurd. It is difficult to imagine that there are implementations that would do so. That said, if we need to spell that out in great and gory detail to get implementors to do the obvious thing, then I guess we need to. I grudgingly support the proposal to document how implementations should treat "atomic fragments". Tim Hartrick > Thoughts? > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --f46d041706e39bcab104b5b777f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Fernando,

On Tue, Jan 3, 2012 at 3:14= PM, Fernando Gont <fgont@si6networks.com> wrote:
Folks,

The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered
some (unintended) discussion about the usefulness/legitimacy of IPv6
"atomic fragments" (IPv6 packets that contain a Fragmentation Hea= der,
but that have the "More Fragments" bit set to zero).


Just to clarify what you mean by an atomic fragme= nt; you mean fragments with an offset of 0 and the "More Fragments&quo= t; flag set to zero.=A0 That is, this is the beginning and there is no more= .
=A0
My understanding is that is quite clear that such packets have been
found in the wild and that a number of things would break if they were
blocked or banned.


They are essential to translation systems.=A0 Fir= ewalls that block them are broken since "atomic fragments" repres= ent no security risk and are a legal part of the protocol.
=A0
That said, I'd like some feedback on the actual proposal in
draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned "atomic fragments" as if they were non-fragmented packets. This w= ould
basically eliminate all the security issues and problems normally
associated with framgentation, while still allowing their legitimate use.

On the one hand I would prefer that this document= not be necessary.=A0 That is, treating "atomic fragments" as not= being fragmented at all is the way that any competent software engineer wo= uld treat them.=A0 The idea of allocating reassembly state and timers for d= atagrams of this sort and then executing anything like the normal reassembl= y logic on them is absurd.=A0 It is difficult to imagine that there are imp= lementations that would do so.

That said, if we need to spell that out in great and gory detail to get= implementors to do the obvious thing, then I guess we need to.=A0 I grudgi= ngly support the proposal to document how implementations should treat &quo= t;atomic fragments".



Tim Hartrick

=A0
Thoughts?

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--f46d041706e39bcab104b5b777f7-- From rja.lists@gmail.com Wed Jan 4 10:47:27 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E487011E8086 for ; Wed, 4 Jan 2012 10:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbRRckhaEVfj for ; Wed, 4 Jan 2012 10:47:27 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC0C11E8079 for ; Wed, 4 Jan 2012 10:47:27 -0800 (PST) Received: by qadz3 with SMTP id z3so11442328qad.10 for ; Wed, 04 Jan 2012 10:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=q9NSLo0wpM+IXXDZ1jLgeypxa/aCLXZMVykBX2hgoTk=; b=rx8xtFt3boZp/bv12HEY8dfxrhzYO1EovoYYfCW05InuzP3ClmAY1jYV3TnCH4qRYc wWXe6up32qrEtpUQuyfJ5U8jGzc7eN9k2nkHUUfVIXG+hfzFwSadJZXZ/3OJB3J9yKGQ XrOR8O9ml0UCKF4+u8EzhjGaK2qvZTsABXoOo= Received: by 10.224.32.20 with SMTP id a20mr67437233qad.61.1325702845643; Wed, 04 Jan 2012 10:47:25 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id el7sm108852471qab.16.2012.01.04.10.47.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 10:47:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Fragmentation-related security issues From: RJ Atkinson In-Reply-To: Date: Wed, 4 Jan 2012 13:47:24 -0500 Content-Transfer-Encoding: 7bit Message-Id: <234D1EAB-838F-4872-B989-917FBB201DD2@gmail.com> References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:47:28 -0000 On 04 Jan 2012, at 10:24 , Philip Homburg wrote: > Yes, but PMTU failures are not a protocol issue. > Is it is an operational issue. So when the IPv6 > network is just a bunch of techies who are connected by > tunnels, you expect PMTU to sort of work. I didn't expect it to work, given the history of PMTU in the deployed Internet. When it does work, PMTU is wonderful. It has not been reliable for IPv4 either. > By the time the internet is big is enough that some > routers just send ICMPs with link local source and > nobody notices, then PMTU starts to break down. We have long standing experience with PMTU. It hasn't been completely reliable for IPv4. It is no surprise that it is not completely reliable for IPv6 either. > I'm sure you know about the small difference between IPv4 and IPv6 > when it comes to fragmentation. For IPv4, if a DNS server need > to send a, say, 1000 octet reply then it can just send it. > If necessary, routers on the way will fragment the reply. Actually, IPv4 routers generally won't fragment the reply for too-big IPv4 packets -- not even if the DF bit allows them to do so. Most deployed IPv4 transit routers disabled all router fragmentation of IPv4 packets years ago. My understanding is that existing DNS servers often choose to send less-than-MTU sized DNS replies in part because of issues with IPv4 PMTU. So, again, this situation is not new with IPv6. > On the other hand, for IPv6, a DNS server will have > to fragment at the lowest common denominator. So making > the minimum link MTU 576, will cause a lot more IPv6 > fragments then you would get for IPv4. And makes IPv6 > quite a bit worse than IPv4. That does not sound identical with other folks' analysis about DNS. For example, that isn't identical with what Mark Andrews has said. > If you follow this to the logical conclusion, then with the > IPv6-IPv4 translators, a DNS server has to add a fragmentation > header to every DNS reply, even the small ones. That does seem consistent with what other folks concerned about DNS have already noted. > Well, you can always tunnel IPv6 over IPv4. Problem solved :-) If there were infinite bandwidth, it would be. Sadly, RF links with smaller MTUs generally are also relatively low data rate -- mostly visibly lower data rate than Ethernet. Yours, Ran From brian.e.carpenter@gmail.com Wed Jan 4 11:13:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9D721F85D6 for ; Wed, 4 Jan 2012 11:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mquYcVXPeMXu for ; Wed, 4 Jan 2012 11:13:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 699D721F85D5 for ; Wed, 4 Jan 2012 11:13:42 -0800 (PST) Received: by eekc14 with SMTP id c14so15799121eek.31 for ; Wed, 04 Jan 2012 11:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ycWFymzQw83D/kxL38oeYfBVebpdpO4eouXr4htwDPg=; b=rfP8gjfrfOK37g3iqE4nE+zLojqOLdeP1rKHJJQ92RfBbmO4XQjKmgLjTGVs5vOk1p EP88O9b7/sx6sum2Ifb8QbZBmhvQdmZd8OIrq24NSTmFKXm2bf7up2hKCPOV7ZvT43tr G/eYj55PWC9pP1gQuqQqyfhGX3A9//KDfpnG8= Received: by 10.14.126.80 with SMTP id a56mr23964486eei.121.1325704421623; Wed, 04 Jan 2012 11:13:41 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id 76sm223266957eeh.0.2012.01.04.11.13.39 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 11:13:40 -0800 (PST) Message-ID: <4F04A4D7.9060508@gmail.com> Date: Thu, 05 Jan 2012 08:13:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Fragmentation-related security issues References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:13:48 -0000 On 2012-01-05 02:57, RJ Atkinson wrote: > Earlier, Mark Andrews wrote: >> Atomic fragments > 1280 should not appear in the network. >> Atomic fragments <= 1280 are a expected part of the IPv6 landscape. >> For TCP they should be rare. >> For UDP it depends on the protocol running on top of UDP. >> PMTUD relying on PTB is just not reliable. > > To the best of my understanding, the above is correct. The last point is IMHO the most significant. As far as I'm concerned, PMTUD for IPv4 has *never* been reliable, and for many years I clamped the MTU on my laptop at 576 to avoid constant connectivity failures while on travel. That seems to have become unnecessary in recent years since 1500 became almost universal as the link MTU (but PMTUD is still unreliable). I see no reason to expect that PMTUD will be more reliable for IPv6 than for IPv4. 1280 is reasonably safe today only because 1500 link MTU is widespread. On 2012-01-05 05:19, Dan Wing wrote: > We can clamp TCP MSS on our various translator devices. However, this won't help with TCP implementations whose MSS negotiation is broken. I haven't seen that failure mode on translated paths, but I have seen it on 6to4 paths, where one end wanted to reduce the MSS and the other end was stuck on 1440. Brian From Fred.L.Templin@boeing.com Wed Jan 4 13:59:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB2111E80C5 for ; Wed, 4 Jan 2012 13:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLOEkIYVhA8x for ; Wed, 4 Jan 2012 13:59:04 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1042A11E80A6 for ; Wed, 4 Jan 2012 13:59:04 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q04LxSL9028966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Jan 2012 15:59:33 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q04LvjCv018978 for ; Wed, 4 Jan 2012 13:58:56 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q04LrTTF005066 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 4 Jan 2012 13:53:41 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 4 Jan 2012 13:53:38 -0800 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Date: Wed, 4 Jan 2012 13:53:36 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczLEVPy8Ep3LTR/T6+DWSeWiW7T5gAGTZ9g Message-ID: References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> <234D1EAB-838F-4872-B989-917FBB201DD2@gmail.com> In-Reply-To: <234D1EAB-838F-4872-B989-917FBB201DD2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:59:04 -0000 =20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of RJ Atkinson > Sent: Wednesday, January 04, 2012 10:47 AM > To: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues=20 >=20 >=20 > On 04 Jan 2012, at 10:24 , Philip Homburg wrote: > > Yes, but PMTU failures are not a protocol issue. > > Is it is an operational issue. So when the IPv6 > > network is just a bunch of techies who are connected by > > tunnels, you expect PMTU to sort of work.=20 >=20 > I didn't expect it to work, given the history of PMTU > in the deployed Internet. When it does work, PMTU is=20 > wonderful. It has not been reliable for IPv4 either. >=20 > > By the time the internet is big is enough that some > > routers just send ICMPs with link local source and > > nobody notices, then PMTU starts to break down. >=20 > We have long standing experience with PMTU. It hasn't > been completely reliable for IPv4. It is no surprise=20 > that it is not completely reliable for IPv6 either. >=20 > > I'm sure you know about the small difference between IPv4 and IPv6 > > when it comes to fragmentation. For IPv4, if a DNS server need > > to send a, say, 1000 octet reply then it can just send it. > > If necessary, routers on the way will fragment the reply. >=20 > Actually, IPv4 routers generally won't fragment the reply > for too-big IPv4 packets -- not even if the DF bit allows > them to do so. Most deployed IPv4 transit routers=20 > disabled all router fragmentation of IPv4 packets=20 > years ago. "Most deployed IPv4 transit routers disabled all router fragmentation of IPv4 packets years ago." Are you sure about that? Because, I have had at least one person from a major router vendor tell me that router fragmentation is well supported in their products. Disabling router fragmentation for DF=3D0 packets seems risky; too many things could break. Fred fred.l.templin@boeing.com =20 > My understanding is that existing DNS servers often > choose to send less-than-MTU sized DNS replies > in part because of issues with IPv4 PMTU. So, again, > this situation is not new with IPv6. >=20 > > On the other hand, for IPv6, a DNS server will have > > to fragment at the lowest common denominator. So making > > the minimum link MTU 576, will cause a lot more IPv6 > > fragments then you would get for IPv4. And makes IPv6 > > quite a bit worse than IPv4. >=20 > That does not sound identical with other folks' analysis > about DNS. For example, that isn't identical with what > Mark Andrews has said. >=20 > > If you follow this to the logical conclusion, then with the > > IPv6-IPv4 translators, a DNS server has to add a fragmentation > > header to every DNS reply, even the small ones. >=20 > That does seem consistent with what other folks concerned > about DNS have already noted. >=20 > > Well, you can always tunnel IPv6 over IPv4. Problem solved :-) >=20 > If there were infinite bandwidth, it would be. Sadly, > RF links with smaller MTUs generally are also relatively > low data rate -- mostly visibly lower data rate than > Ethernet. >=20 > Yours, >=20 > Ran >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From fgont@si6networks.com Wed Jan 4 14:01:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AD211E80C5 for ; Wed, 4 Jan 2012 14:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLcuynhsTmbP for ; Wed, 4 Jan 2012 14:01:57 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id A416A11E80A6 for ; Wed, 4 Jan 2012 14:01:57 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiYu8-0001cZ-0a; Wed, 04 Jan 2012 23:01:52 +0100 Message-ID: <4F03BCD9.2080101@si6networks.com> Date: Tue, 03 Jan 2012 23:43:37 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <298C387E-66C2-4558-8ACF-441A56A7D501@lists.zabbadoz.net> In-Reply-To: <298C387E-66C2-4558-8ACF-441A56A7D501@lists.zabbadoz.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:01:58 -0000 On 01/03/2012 08:51 PM, Bjoern A. Zeeb wrote: >> On 01/02/2012 07:48 PM, Bjoern A. Zeeb wrote: >>> You'd need to go to the origins most likely and get into touch with them, >>> ask them, work with them to identify things and see if you can find a >>> common denominator... >>> >>> It might really be worth doing so; in case we are hunting misconfigurations >>> or bugs here and discussing the merits on how to handle other than drop;-) >> >> Why should you drop in this case, when it's trivial to process these >> fragments safely, with no side effects?? > > Because a fragment header that's not needed a) heats the planet, b-z) does > all the things what that means. The more we can force that not to happen > the better we are off. Huh? If there was no way to avoid, problems, I'd agree. However, there is (see my I-D on IPv6 atomic fragments). Regarding the usefulness/need for atomic fragments, it had been described already by Ran Atkinson, Mark Andrews, and others. You want to filter them out? -- You break stuff. It's that simple. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jan 4 14:02:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A1221F858B for ; Wed, 4 Jan 2012 14:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGoDdVHyr-TY for ; Wed, 4 Jan 2012 14:02:15 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 62B4821F8585 for ; Wed, 4 Jan 2012 14:02:15 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiYuN-0001cc-MS; Wed, 04 Jan 2012 23:02:08 +0100 Message-ID: <4F03BD43.5000706@si6networks.com> Date: Tue, 03 Jan 2012 23:45:23 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Dan Wing Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F036C3B.5030403@dougbarton.us> <031701ccca7f$5ade7ed0$109b7c70$@com> In-Reply-To: <031701ccca7f$5ade7ed0$109b7c70$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:02:16 -0000 On 01/03/2012 10:22 PM, Dan Wing wrote: >> ... and this is not a feature because? And no, don't quote the >> robustness principle. The floor for MTU has been hard-coded since day >> 1, so anyone who breaks that deserves what they get. > > Yes, I agree, the last paragraph of > http://tools.ietf.org/html/rfc2460#section-5 has been around > a long time, and IPv6 hosts should follow it. > > If there is consensus otherwise, we (the collective "we") need > to acknowledge what that breaks. It would be pretty dumb to break stuff with no gains. -- Particularly when there are lots of things to tighten up (which *do* have security implications). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dougb@dougbarton.us Wed Jan 4 14:02:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19BF11E80D9 for ; Wed, 4 Jan 2012 14:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRPP5U+178Hi for ; Wed, 4 Jan 2012 14:02:39 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3BE11E80D8 for ; Wed, 4 Jan 2012 14:02:38 -0800 (PST) Received: (qmail 7222 invoked by uid 399); 4 Jan 2012 22:02:35 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 4 Jan 2012 22:02:35 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F04CC7A.9090700@dougbarton.us> Date: Wed, 04 Jan 2012 14:02:34 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Fragmentation-related security issues References: <92CD3301-2BCA-43A5-8C08-97AC0F8E6B6B@gmail.com> In-Reply-To: <92CD3301-2BCA-43A5-8C08-97AC0F8E6B6B@gmail.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:02:40 -0000 On 01/04/2012 05:55, RJ Atkinson wrote: > Earlier, Doug Barton wrote: >> On 01/03/2012 11:02, Dan Wing wrote: >>> If IPv6 hosts don't handle >>> ICMP packet-too-big of less than 1280, those IPv4/IPv6 translators >>> won't work with sub-1280 MTU IPv4 paths. >> >> ... and this is not a feature because? And no, don't quote the >> robustness principle. The floor for MTU has been hard-coded since day 1, >> so anyone who breaks that deserves what they get. > > In fact, the MTU floor CHANGED from 576 to 1280 well AFTER day 1, Technically you're correct of course, but for all practical values of "day 1" I think my point remains valid. > Separately, I'm old enough to believe in the robustness > principle -- because Jon Postel's argument for it was > (and remains) quite correct. In the abstract, sure. But to what extent does that argument apply to people who made a best effort at following the spec and didn't get it done exactly the way that you did; and to what extent does it apply to people who say "Screw the spec, I'm gonna do it this way, you sort it out." Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From Fred.L.Templin@boeing.com Wed Jan 4 14:07:25 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8AE21F85AC for ; Wed, 4 Jan 2012 14:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T220eZSf2ex for ; Wed, 4 Jan 2012 14:07:24 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id B336821F85A6 for ; Wed, 4 Jan 2012 14:07:24 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q04M7Km5000470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Jan 2012 14:07:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q04M7589024110 for ; Wed, 4 Jan 2012 14:07:17 -0800 (PST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q04M6TIg022418 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 4 Jan 2012 14:06:35 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Wed, 4 Jan 2012 14:06:31 -0800 From: "Templin, Fred L" To: Brian E Carpenter , "ipv6@ietf.org" Date: Wed, 4 Jan 2012 14:06:31 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczLFQMMH4bv7oKuStKIIUpfGu1I4QAF1PTQ Message-ID: References: <4F04A4D7.9060508@gmail.com> In-Reply-To: <4F04A4D7.9060508@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:07:25 -0000 =20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian E Carpenter > Sent: Wednesday, January 04, 2012 11:13 AM > To: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 2012-01-05 02:57, RJ Atkinson wrote: > > Earlier, Mark Andrews wrote: > >> Atomic fragments > 1280 should not appear in the network. =20 > >> Atomic fragments <=3D 1280 are a expected part of the IPv6=20 > landscape. =20 > >> For TCP they should be rare. =20 > >> For UDP it depends on the protocol running on top of UDP. =20 > >> PMTUD relying on PTB is just not reliable. > >=20 > > To the best of my understanding, the above is correct. >=20 > The last point is IMHO the most significant. As far as I'm > concerned, PMTUD for IPv4 has *never* been reliable, and for > many years I clamped the MTU on my laptop at 576 to avoid > constant connectivity failures while on travel. That seems > to have become unnecessary in recent years since 1500 became > almost universal as the link MTU (but PMTUD is still unreliable). >=20 > I see no reason to expect that PMTUD will be more reliable for > IPv6 than for IPv4. I think a lot is now hinging on the assumption that PMTUD for IPv6 works. Unlike the situation for IPv4, I see no reason to expect that PMTUD for IPv6 will be unreliable. > 1280 is reasonably safe today only because > 1500 link MTU is widespread. On this point, I agree that 1280 fits within the current day Internet cell size (1500) even if there are multiple levels of encapsulation. But, I see no reason why IPv6 PMTUD can't be counted upon for larger than 1280. Fred fred.l.templin@boeing.com > On 2012-01-05 05:19, Dan Wing wrote: >=20 > > We can clamp TCP MSS on our various translator devices. >=20 > However, this won't help with TCP implementations whose > MSS negotiation is broken. I haven't seen that failure > mode on translated paths, but I have seen it on 6to4 paths, > where one end wanted to reduce the MSS and the other end > was stuck on 1440. >=20 > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From dougb@dougbarton.us Wed Jan 4 14:12:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0023D11E80CF for ; Wed, 4 Jan 2012 14:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzXbLa6yA0mQ for ; Wed, 4 Jan 2012 14:12:19 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id F186C11E80B6 for ; Wed, 4 Jan 2012 14:12:18 -0800 (PST) Received: (qmail 19221 invoked by uid 399); 4 Jan 2012 22:12:13 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 4 Jan 2012 22:12:13 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F04CEBC.3060600@dougbarton.us> Date: Wed, 04 Jan 2012 14:12:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F036C3B.5030403@dougbarton.us> <031701ccca7f$5ade7ed0$109b7c70$@com> <4F03BD43.5000706@si6networks.com> In-Reply-To: <4F03BD43.5000706@si6networks.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:12:20 -0000 On 01/03/2012 18:45, Fernando Gont wrote: > On 01/03/2012 10:22 PM, Dan Wing wrote: >>> ... and this is not a feature because? And no, don't quote the >>> robustness principle. The floor for MTU has been hard-coded since day >>> 1, so anyone who breaks that deserves what they get. >> >> Yes, I agree, the last paragraph of >> http://tools.ietf.org/html/rfc2460#section-5 has been around >> a long time, and IPv6 hosts should follow it. >> >> If there is consensus otherwise, we (the collective "we") need >> to acknowledge what that breaks. > > It would be pretty dumb to break stuff with no gains. Completely aside from the intrinsic value of "People who follow the spec get the benefits of interoperability; people who don't, don't." Not having to deal with an MTU of less than the minimum for IPv6 keeps code simple. Simple is good. IMO that's a pretty big gain, and an enormous loss if everyone who's ever deployed IPv6 code has to go back and reexamine that fundamental assumption. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From fgont@si6networks.com Wed Jan 4 14:18:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9875B21F85E8 for ; Wed, 4 Jan 2012 14:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kldI5KVQRpMt for ; Wed, 4 Jan 2012 14:18:36 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 1856921F85E4 for ; Wed, 4 Jan 2012 14:18:36 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiYus-0001dH-Nx; Wed, 04 Jan 2012 23:02:39 +0100 Message-ID: <4F048DD2.9050107@si6networks.com> Date: Wed, 04 Jan 2012 14:35:14 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <82ehvfnakx.fsf@mid.bfk.de> In-Reply-To: <82ehvfnakx.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:18:36 -0000 On 01/04/2012 05:19 AM, Florian Weimer wrote: >> Why should you drop in this case, when it's trivial to process these >> fragments safely, with no side effects?? > > Do we really know that adding a fragment header to all outgoing packets > does not cause them to be rejected? Are you arguing that IPv6 fragmentation does no work at all, or what? My take is that packets won't be rejected simply for having a Fragment Header. They *will* probably be rejected if the initial fragment does not contain all the relevant headers, though (IPv6+transport). > Could this be deployed at large DNS > servers in a risk-free fashion, for instance? What's the specific question you're asking, and what is your concern, specifically? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jan 4 14:18:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FE421F85E4 for ; Wed, 4 Jan 2012 14:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.166 X-Spam-Level: X-Spam-Status: No, score=-0.166 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB8nINwLy2b6 for ; Wed, 4 Jan 2012 14:18:36 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 8111121F85E1 for ; Wed, 4 Jan 2012 14:18:36 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiYux-0001dV-UH; Wed, 04 Jan 2012 23:02:44 +0100 Message-ID: <4F04AA46.6090806@si6networks.com> Date: Wed, 04 Jan 2012 16:36:38 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Timothy Hartrick Subject: Re: Atomic fragments: converging on something? References: <4F038BD2.6080805@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:18:37 -0000 On 01/04/2012 02:51 PM, Timothy Hartrick wrote: > Folks, > > The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt triggered > some (unintended) discussion about the usefulness/legitimacy of IPv6 > "atomic fragments" (IPv6 packets that contain a Fragmentation Header, > but that have the "More Fragments" bit set to zero). > > > Just to clarify what you mean by an atomic fragment; you mean fragments > with an offset of 0 and the "More Fragments" flag set to zero. That is, > this is the beginning and there is no more. Yes, exactly. (Sorry for the confusion! -- 24-hours working on code without any sleep (literally) did have their effect on me, it seems... :-( ) > My understanding is that is quite clear that such packets have been > found in the wild and that a number of things would break if they were > blocked or banned. > > > They are essential to translation systems. Firewalls that block them > are broken since "atomic fragments" represent no security risk and are a > legal part of the protocol. That's my take, too. > That said, I'd like some feedback on the actual proposal in > draft-gont-6man-ipv6-atomic-fragments-00.txt: process the aforementioned > "atomic fragments" as if they were non-fragmented packets. This would > basically eliminate all the security issues and problems normally > associated with framgentation, while still allowing their legitimate > use. > > On the one hand I would prefer that this document not be necessary. > That is, treating "atomic fragments" as not being fragmented at all is > the way that any competent software engineer would treat them. The idea > of allocating reassembly state and timers for datagrams of this sort and > then executing anything like the normal reassembly logic on them is > absurd. It is difficult to imagine that there are implementations that > would do so. Test some of them, and you'll see. :-) > That said, if we need to spell that out in great and gory detail to get > implementors to do the obvious thing, then I guess we need to. I > grudgingly support the proposal to document how implementations should > treat "atomic fragments". Thanks, for your support. My experience with this sort of corner cases is that unless you explicitly say what should be done, you cannot assume that implementers will follow your own logic (even if it's supposed to be obvious). Sometimes it takes time and discussion (such as that in this thread) for us (protocol types :-) ) to converge on something.. so it shouldn't be surprising that someone working on tons of patches doesn't spend some time trying to get every detail right. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From albert.e.manfredi@boeing.com Wed Jan 4 14:37:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D98321F8602 for ; Wed, 4 Jan 2012 14:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaLsKBYivizU for ; Wed, 4 Jan 2012 14:37:30 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id B05A821F85F3 for ; Wed, 4 Jan 2012 14:37:30 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q04MbRvc005438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jan 2012 14:37:27 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q04MbRcC026323; Wed, 4 Jan 2012 14:37:27 -0800 (PST) Received: from XCH-MWHT-04.mw.nos.boeing.com (xch-mwht-04.mw.nos.boeing.com [134.57.113.164]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q04MbQWF026283 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 4 Jan 2012 14:37:26 -0800 (PST) Received: from XCH-MWPFX-01.mw.nos.boeing.com (132.173.24.10) by XCH-MWHT-04.mw.nos.boeing.com (134.57.113.164) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Jan 2012 16:37:25 -0600 Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWPFX-01.mw.nos.boeing.com ([132.173.24.10]) with mapi; Wed, 4 Jan 2012 16:37:25 -0600 From: "Manfredi, Albert E" To: Dan Wing Date: Wed, 4 Jan 2012 16:37:23 -0600 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczKxWPhjyUkE1yoRqGV+gV2FmRGVgANf/lAAAx0a7A= Message-ID: References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> <01f701ccca58$4b7bd040$e27370c0$@com> <4581455F-282E-42E6-B328-CEB06620C844@free.fr> <043801cccafb$f754beb0$e5fe3c10$@com> In-Reply-To: <043801cccafb$f754beb0$e5fe3c10$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18626.002 x-tm-as-result: No--73.103500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:37:31 -0000 Perhaps we should go back to what 576 bytes really was, in IPv4, and apply = the same rules to IPv6. 576 bytes is NOT the smallest MTU allowable in an IPv4 path. It refers to t= he smallest packet that must be able to be de-fragmented, in IPv4. Why can'= t we apply a similar rule to IPv6? >From RFC 791: Every internet module must be able to forward a datagram of 68 octets without further fragmentation. This is because an internet header may be up to 60 octets, and the minimum fragment is 8 octets. Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. The minimum MTU for IPv4 is 68 bytes. Similarly, in IPv6, PMTU *should* be = allowed to be as small as 40 bytes + 8 bytes for the fragmentation header += any more required by other options, as determined by the source host. I know RFC 2460 doesn't read this way, but I believe this issue could be re= solved by going back to what RFC 791 really said. Bert -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Dan= Wing Sent: Wednesday, January 04, 2012 11:15 AM To: 'R=E9mi Despr=E9s' Cc: ipv6@ietf.org; 'Brian E Carpenter' Subject: RE: Fragmentation-related security issues > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Wednesday, January 04, 2012 1:44 AM > To: Dan Wing > Cc: 'Brian E Carpenter'; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > Hi Dan, >=20 > As you rightly reminded, the current specification permits PTB<1280 for > a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids it > for an IPv6 DST. >=20 > Rather than changing this, what about clarifying that a host SHOULD > treat a received PTB>1280 as: > - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 of > RFC6147) That only helps in half of the RFC6144 scenarios, where the IPv6 host is behind the translator (e.g., "Scenario 1: an IPv6 network to the IPv4 Internet"). It would not help in the other half of the RFC6144 scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4: an IPv4 network to the IPv6 Internet"). It is RFC6144's Scenario 4 where stateless IPv6/IPv4 translators, where the IPv4 network has a small MTU, that there is a reliance on the last paragraph of Section 5 of RFC2460. -d > - an ERROR otherwise. >=20 > This would at least dissuade from tolerating IPv6 paths with PMTU < > 1280. >=20 > RD >=20 >=20 >=20 > Le 2012-01-03 =E0 21:43, Dan Wing a =E9crit : > >> ... > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> ... > >> On 2012-01-04 08:02, Dan Wing wrote: > >>> ... > >>> So, I don't think we can just wish away packet-too-big < 1280. > >> > >> Sadly, that seems to be true unless we make a much more radical > change, > >> because of translators. > > > > Or, we declare a new restriction that translators are not expected to > > work if the IPv4 network has an MTU less than 1260 (1260=3D1280-20, > > because IPv6 header is 20B bigger than IPv4 header). I don't know if > there > > is consensus for such a restriction. To date, both RFC2765 and > RFC6145 > > avoided such a restriction. However, if there are widespread IPv6 > > host implementations or firewalls that erroneously filter or ignore > > ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to > > accept that restriction, and modify their IPv4 networks to have > > MTU>=3D1260. Such IPv4 network modifications would add to further > > pain to IPv6 coexistence. MTU research by Ben Stasiewicz and > > Matthew Luckie (WAND), published and presented at RIPE and > > other conferences, shows a 2-3% failure rate to various popular > > web sites. They did additional testing during World IPv6 Day, > > but I haven't dug into those results yet. > > > > -d > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From fgont@si6networks.com Wed Jan 4 14:41:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1FC11E809D for ; Wed, 4 Jan 2012 14:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.251 X-Spam-Level: X-Spam-Status: No, score=-0.251 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk19Wwe00qP8 for ; Wed, 4 Jan 2012 14:41:50 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 6E41311E8089 for ; Wed, 4 Jan 2012 14:41:50 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiZWi-0001sI-28; Wed, 04 Jan 2012 23:41:44 +0100 Message-ID: <4F04D11B.1010500@si6networks.com> Date: Wed, 04 Jan 2012 19:22:19 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Fragmentation-related security issues References: <4F04A4D7.9060508@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:41:51 -0000 On 01/04/2012 07:06 PM, Templin, Fred L wrote: >> I see no reason to expect that PMTUD will be more reliable for >> IPv6 than for IPv4. > > I think a lot is now hinging on the assumption that > PMTUD for IPv6 works. Unlike the situation for IPv4, > I see no reason to expect that PMTUD for IPv6 will > be unreliable. It has been found to break, already -- as a result of firewalls filtering ICMPv6 messages, are some intermediate systems with inappropriate rate limiting for all ICMPv6 traffic. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Wed Jan 4 14:41:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3AB11E809D for ; Wed, 4 Jan 2012 14:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If7t1q-+IOSM for ; Wed, 4 Jan 2012 14:41:51 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0236311E8089 for ; Wed, 4 Jan 2012 14:41:51 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiZWo-0001sL-0q; Wed, 04 Jan 2012 23:41:50 +0100 Message-ID: <4F04D570.6030100@si6networks.com> Date: Wed, 04 Jan 2012 19:40:48 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Fragmentation-related security issues References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:41:51 -0000 On 01/04/2012 10:57 AM, RJ Atkinson wrote: > Earlier, Mark Andrews wrote: >> Atomic fragments > 1280 should not appear in the network. >> Atomic fragments <= 1280 are a expected part of the IPv6 landscape. >> For TCP they should be rare. How about stateless translators translating TCP traffic, and sending an ICMPv6 PTB traffic for the same reasons as discussed for the UDP case? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Wed Jan 4 14:44:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D311E80F6 for ; Wed, 4 Jan 2012 14:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGfGNPdV2abo for ; Wed, 4 Jan 2012 14:44:04 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F91211E80F4 for ; Wed, 4 Jan 2012 14:44:04 -0800 (PST) Received: by qcsf15 with SMTP id f15so12740448qcs.31 for ; Wed, 04 Jan 2012 14:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=dt2zI7r7QUyoWYfhRs1e5qafg9BMPrQEaWsCByHcd8A=; b=CurCab+AEPvRvDY7jxYqaxWEig/QZw4H3F2NHFlX4VhKSmSzoJ8ybB4DLSrTyWtMTF DV5pa820XFjAMVSzi6uOVEzP/X3gFiKhi8hfSoSL5TdxXJjkZqY+ywpKczgVib4nBRJV LMRc7P/vL4fflTMpJyiulGCpv8Q+1XIq05oec= Received: by 10.229.102.163 with SMTP id g35mr19254046qco.78.1325717044071; Wed, 04 Jan 2012 14:44:04 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id h9sm110410705qac.13.2012.01.04.14.44.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 14:44:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Fragmentation-related security issues From: RJ Atkinson In-Reply-To: Date: Wed, 4 Jan 2012 17:44:01 -0500 Content-Transfer-Encoding: 7bit Message-Id: <11D8788A-C91F-4B70-8CF4-2F59699891C8@gmail.com> References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> <234D1EAB-838F-4872-B989-917FBB201DD2@gmail.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:44:05 -0000 On 04 Jan 2012, at 16:53 , Templin, Fred L wrote: > "Most deployed IPv4 transit routers disabled all router > fragmentation of IPv4 packets years ago." Are you sure > about that? Because, I have had at least one person from > a major router vendor tell me that router fragmentation > is well supported in their products. I have no doubt their product possesses the capability. That is subtly different from folks responsible for configuring routers disabling that capability in particular routers of a particular deployment. I was referring to the latter, not the former. My apologies for being unclear. Yours, Ran From rja.lists@gmail.com Wed Jan 4 14:46:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14E511E80EA for ; Wed, 4 Jan 2012 14:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.627 X-Spam-Level: X-Spam-Status: No, score=-3.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGkVT6B83b4i for ; Wed, 4 Jan 2012 14:46:29 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFA211E80E4 for ; Wed, 4 Jan 2012 14:46:29 -0800 (PST) Received: by qadb15 with SMTP id b15so10548899qad.10 for ; Wed, 04 Jan 2012 14:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=Mxo71O7vxbF1OHfou7eBBnjPc3ZfTiqdLS0qEuWZHUQ=; b=h1WS6VZto3qWuKxiFuQeWt+99NbT9H/7AJX7MMDwuWsel/IHRbCZnJZkiic3cKx6Vz 81lGlFgqivh9BfSecckyek82XHPhJtJ66cbp/VgBN2yI9GlbpePObWhssiE1A0r9viVg ACJDigyKt/dX/4LNGcahOjIDdA3VB0BeF8rPo= Received: by 10.224.210.10 with SMTP id gi10mr56355320qab.27.1325717188855; Wed, 04 Jan 2012 14:46:28 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id dk2sm41905957qab.12.2012.01.04.14.46.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 14:46:28 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Fragmentation-related security issues From: RJ Atkinson In-Reply-To: <4F04D570.6030100@si6networks.com> Date: Wed, 4 Jan 2012 17:46:26 -0500 Content-Transfer-Encoding: 7bit Message-Id: <9C009E40-52DB-47BC-BC03-034D304EE9E6@gmail.com> References: <4F04D570.6030100@si6networks.com> To: ipv6@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:46:29 -0000 On 04 Jan 2012, at 17:40 , Fernando Gont wrote: >> Earlier, Mark Andrews wrote: >>> Atomic fragments > 1280 should not appear in the network. >>> Atomic fragments <= 1280 are a expected part of the IPv6 landscape. >>> For TCP they should be rare. > > How about stateless translators translating TCP traffic, and sending an > ICMPv6 PTB traffic for the same reasons as discussed for the UDP case? Good point. From wwwrun@rfc-editor.org Wed Jan 4 14:47:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5E421F8733 for ; Wed, 4 Jan 2012 14:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.335 X-Spam-Level: X-Spam-Status: No, score=-102.335 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRphBkb0USWA for ; Wed, 4 Jan 2012 14:47:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 12A4721F86E7 for ; Wed, 4 Jan 2012 14:47:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8C7B872E004; Wed, 4 Jan 2012 14:45:17 -0800 (PST) To: edward.jankiewicz@sri.com, john.loughney@nokia.com, narten@us.ibm.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, bob.hinden@gmail.com, brian@innovationslab.net Subject: [Editorial Errata Reported] RFC6434 (3073) From: RFC Errata System Message-Id: <20120104224517.8C7B872E004@rfc-editor.org> Date: Wed, 4 Jan 2012 14:45:17 -0800 (PST) Cc: john.loughney@nokia.com, ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:47:40 -0000 The following errata report has been submitted for RFC6434, "IPv6 Node Requirements". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6434&eid=3073 -------------------------------------- Type: Editorial Reported by: John Loughney Section: 15.2 Original Text ------------- 15.2. Authors and Acknowledgments from RFC 4279 The original version of this document (RFC 4279) was written by the IPv6 Node Requirements design team: Corrected Text -------------- 15.2. Authors and Acknowledgments from RFC 4294 The original version of this document (RFC 4294 ) was written by the IPv6 Node Requirements design team: Notes ----- RFC 4279 is the TLS RFC. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6434 (draft-ietf-6man-node-req-bis-11) -------------------------------------- Title : IPv6 Node Requirements Publication Date : December 2011 Author(s) : E. Jankiewicz, J. Loughney, T. Narten Category : INFORMATIONAL Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From Fred.L.Templin@boeing.com Wed Jan 4 14:51:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9976921F8782 for ; Wed, 4 Jan 2012 14:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVqToEZaZXND for ; Wed, 4 Jan 2012 14:51:08 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1640721F877A for ; Wed, 4 Jan 2012 14:51:08 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q04MpPAc025931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jan 2012 16:51:30 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q04MoqMR018168; Wed, 4 Jan 2012 14:50:52 -0800 (PST) Received: from XCH-NWHT-06.nw.nos.boeing.com (xch-nwht-06.nw.nos.boeing.com [130.247.25.110]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q04MogDv017913 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 4 Jan 2012 14:50:42 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-06.nw.nos.boeing.com ([130.247.25.110]) with mapi; Wed, 4 Jan 2012 14:50:42 -0800 From: "Templin, Fred L" To: Fernando Gont Date: Wed, 4 Jan 2012 14:50:41 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczLMg5PM59MSoMhQoeronUVkOccaAAAPihw Message-ID: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> In-Reply-To: <4F04D11B.1010500@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:51:08 -0000 =20 > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com]=20 > Sent: Wednesday, January 04, 2012 2:22 PM > To: Templin, Fred L > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 01/04/2012 07:06 PM, Templin, Fred L wrote: > >> I see no reason to expect that PMTUD will be more reliable for > >> IPv6 than for IPv4. > >=20 > > I think a lot is now hinging on the assumption that > > PMTUD for IPv6 works. Unlike the situation for IPv4, > > I see no reason to expect that PMTUD for IPv6 will > > be unreliable. >=20 > It has been found to break, already -- as a result of firewalls > filtering ICMPv6 messages, are some intermediate systems with > inappropriate rate limiting for all ICMPv6 traffic. If IPv6 PMTUD breaks, it is due to violations of the specs. If IPv6 PMTUD breaks, then we are lost - time to give up and design a different protocol? Fred > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > = From Fred.L.Templin@boeing.com Wed Jan 4 15:11:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D8111E80A2 for ; Wed, 4 Jan 2012 15:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vBPsRuoT3rY for ; Wed, 4 Jan 2012 15:11:46 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 26D3121F8573 for ; Wed, 4 Jan 2012 15:11:46 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q04NBaQt001474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 4 Jan 2012 15:11:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q04NBapB025699 for ; Wed, 4 Jan 2012 15:11:36 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q04NBTD9025538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 4 Jan 2012 15:11:30 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Wed, 4 Jan 2012 15:11:29 -0800 From: "Templin, Fred L" To: RJ Atkinson , "ipv6@ietf.org" Date: Wed, 4 Jan 2012 15:11:28 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczLMmH4VuumNMDHSsuBqFUYWbso2wAAPAzg Message-ID: References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> <234D1EAB-838F-4872-B989-917FBB201DD2@gmail.com> <11D8788A-C91F-4B70-8CF4-2F59699891C8@gmail.com> In-Reply-To: <11D8788A-C91F-4B70-8CF4-2F59699891C8@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:11:46 -0000 Hi Ran,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of RJ Atkinson > Sent: Wednesday, January 04, 2012 2:44 PM > To: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues=20 >=20 >=20 > On 04 Jan 2012, at 16:53 , Templin, Fred L wrote: > > "Most deployed IPv4 transit routers disabled all router > > fragmentation of IPv4 packets years ago." Are you sure > > about that? Because, I have had at least one person from > > a major router vendor tell me that router fragmentation > > is well supported in their products. >=20 > I have no doubt their product possesses the capability. > That is subtly different from folks responsible for > configuring routers disabling that capability in=20 > particular routers of a particular deployment. This can only be done at the peril of black-holing DF=3D0 packets that are too large. Meaning, either the responsible folks have a high degree of certainty that their core links will pass the packets w/o loss due to an MTU restriction, or they just don't care that large packets are silently lost. So, it has to be the former since folks that just don't care don't stay in business. This current "pool pah" of FUD reminds me of the one that transpired at the 2002 v6ops interim meeting when the subject of tunnel MTU got started. Others may choose to repeat that, but I've personally seen enough of it for one lifetime. Thanks - Fred > I was referring to the latter, not the former. > My apologies for being unclear. >=20 > Yours, >=20 > Ran >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From fgont@si6networks.com Wed Jan 4 15:52:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB5B21F85D2 for ; Wed, 4 Jan 2012 15:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcq1n1bBVv8s for ; Wed, 4 Jan 2012 15:52:15 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 53A8321F85CD for ; Wed, 4 Jan 2012 15:52:15 -0800 (PST) Received: from [190.48.252.193] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Riacr-0003Lj-NP; Thu, 05 Jan 2012 00:52:10 +0100 Message-ID: <4F04E622.4040702@si6networks.com> Date: Wed, 04 Jan 2012 20:52:02 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: RJ Atkinson Subject: Re: Fragmentation-related security issues References: <4F04D570.6030100@si6networks.com> <9C009E40-52DB-47BC-BC03-034D304EE9E6@gmail.com> In-Reply-To: <9C009E40-52DB-47BC-BC03-034D304EE9E6@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:52:17 -0000 On 01/04/2012 07:46 PM, RJ Atkinson wrote: >> How about stateless translators translating TCP traffic, and sending an >> ICMPv6 PTB traffic for the same reasons as discussed for the UDP case? > > Good point. My take is: As noted in draft-gont-6man-ipv6-atomic-fragments, just process such atomic fragments as non fragmented traffic, and be done with it. Trying to make a distinction whether atomic fragments <1280 should be allowed or not (and trying to figure out what we'd break in the process) doesn't make much sense, since such fragments can be processed (regardless of their size) as safely as non-fragmented traffic. Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From shane@castlepoint.net Wed Jan 4 15:59:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC73A11E809D for ; Wed, 4 Jan 2012 15:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RCnaZjb2oft for ; Wed, 4 Jan 2012 15:59:33 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id E927F11E80A2 for ; Wed, 4 Jan 2012 15:59:32 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id CC392268063; Wed, 4 Jan 2012 16:59:31 -0700 (MST) Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 04 Jan 2012 16:59:31 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56926; data-bytes=0 Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 4 Jan 2012 16:59:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7BADE4FF-6F83-4503-A60B-1341716B53C7@castlepoint.net> References: <924E7CBF-3DF9-49FA-9A89-96806B8F3A9F@gmail.com> <8DD5776F-9CF9-4B9C-B063-C3747EA96435@gmail.com> <234D1EAB-838F-4872-B989-917FBB201DD2@gmail.com> <11D8788A-C91F-4B70-8CF4-2F59699891C8@gmail.com> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1251.1) Cc: "ipv6@ietf.org" , RJ Atkinson X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:59:33 -0000 Fred, Ran, On Jan 4, 2012, at 4:11 PM, Templin, Fred L wrote: > Hi Ran,=20 >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 >> Behalf Of RJ Atkinson >> Sent: Wednesday, January 04, 2012 2:44 PM >> To: ipv6@ietf.org >> Subject: Re: Fragmentation-related security issues=20 >>=20 >>=20 >> On 04 Jan 2012, at 16:53 , Templin, Fred L wrote: >>> "Most deployed IPv4 transit routers disabled all router >>> fragmentation of IPv4 packets years ago." Are you sure >>> about that? Because, I have had at least one person from >>> a major router vendor tell me that router fragmentation >>> is well supported in their products. >>=20 >> I have no doubt their product possesses the capability. >> That is subtly different from folks responsible for >> configuring routers disabling that capability in=20 >> particular routers of a particular deployment. >=20 > This can only be done at the peril of black-holing > DF=3D0 packets that are too large. Meaning, either the > responsible folks have a high degree of certainty that > their core links will pass the packets w/o loss due to > an MTU restriction, or they just don't care that large > packets are silently lost. So, it has to be the former > since folks that just don't care don't stay in business. Just to shed some current operational reality to this thread. There are = providers who are using 6PE as the means to transport IPv6 packets over = a theoretically IPv4-only core/Backbone[1]. One of the chief design = principles of 6PE is that those "IPv4-only" Core LSR's only know of IPv4 = routes (and, IPv4 routing) and do not have any knowledge/understanding = of IPv6. As such, if/when a Core LSR in a 6PE Backbone receives a = IPv6/MPLS packet, i.e.: due to Hop-Limit expired or, in this case, the = Core LSR considers it too big to label-switch out the outgoing interface = ... the "simple", but ugly, answer is for the Core LSR to drop the = IPv6/MPLS packet on the floor. Fortunately, most providers should be = clued in to this "limitation" of 6PE and (should) have Core links set to = use [very] large Jumbo frames, thus working around the issue of needing = Core LSR's to generate PTB's back to the source. One potential = workaround to the Hop-Limit issue is to use "TTL-hiding" on LSP's, but = that tends to be frowned on by Operations folks and customers who = rightfully want to be able to use traceroute and cut+paste output that = shows where along a path something in broken ... In short, 6PE *was* a decent stop-gap technology, but should be put out = to pasture sooner rather than later. Although dual-stack on Core = devices is one answer, another one would be support for MPLS-signaling = protocols (LDP & RSVP) that use native, IPv6 for Transport, which has = kind of been on the back-burner -- although some of us have been trying = to push it's development more and more. -shane [1] Reasons which were likely valid as of just a few years ago, but are = no longer so. > This current "pool pah" of FUD reminds me of the one > that transpired at the 2002 v6ops interim meeting when > the subject of tunnel MTU got started. Others may > choose to repeat that, but I've personally seen enough > of it for one lifetime. >=20 > Thanks - Fred >=20 >> I was referring to the latter, not the former. >> My apologies for being unclear. >>=20 >> Yours, >>=20 >> Ran >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dwing@cisco.com Wed Jan 4 18:45:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483D711E8079 for ; Wed, 4 Jan 2012 18:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.14 X-Spam-Level: X-Spam-Status: No, score=-106.14 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LrAIUjNCaKl for ; Wed, 4 Jan 2012 18:45:33 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 6738211E8072 for ; Wed, 4 Jan 2012 18:45:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=5116; q=dns/txt; s=iport; t=1325731533; x=1326941133; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=K8unciMxF5087k6TFk5fdzrdkEjZGY5PRrr52hEyqYU=; b=LhOymSqIfdqRvzjbT5dfy2/rKBqHJIV53u5XHZq3djqk7K2AxcTYJUQg O/XyFlmx2GwxXfXLfQTQY1mPFTxCw6lG/1c+LtPG0B3CMuO9wDCewu+I8 3KGvS5TY+ik8BkWDpeAA/gWMOgwSGzq12iNkSGXiXupldEyUdCJ7KZ7WM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKwNBU+rRDoJ/2dsb2JhbABDnhOOX4EFgXIBAQEDAQEBAQUKARc+BgsFBwEDAgkPAgQBAQEnBxkIBhUKCQgBAQQTCxeHWAiXHwGdewSMEQSIBjOEeQGSQYdm X-IronPort-AV: E=Sophos;i="4.71,459,1320624000"; d="scan'208";a="23890812" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 05 Jan 2012 02:45:33 +0000 Received: from dwingWS ([10.32.240.197]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q052jWVI010153; Thu, 5 Jan 2012 02:45:32 GMT From: "Dan Wing" To: "=?iso-8859-1?Q?'R=E9mi_Despr=E9s'?=" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> <01f701ccca58$4b7bd040$e27370c0$@com> <4581455F-282E-42E6-B328-CEB06620C844@free.fr> <043801cccafb$f754beb0$e5fe3c10$@com> In-Reply-To: Subject: RE: Fragmentation-related security issues Date: Wed, 4 Jan 2012 18:45:30 -0800 Message-ID: <061d01cccb54$185a8a60$490f9f20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczLCNfxPlpkIT5NTVCSB7lsAdc/4AAScd4A Content-Language: en-us Cc: draft-chen-v6ops-nat64-cpe@tools.ietf.org, ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 02:45:34 -0000 > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Wednesday, January 04, 2012 9:47 AM > To: Dan Wing > Cc: 'Brian E Carpenter'; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > Le 2012-01-04 =E0 17:14, Dan Wing a =E9crit : >=20 > >> -----Original Message----- > >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > >> Sent: Wednesday, January 04, 2012 1:44 AM > >> To: Dan Wing > >> Cc: 'Brian E Carpenter'; ipv6@ietf.org > >> Subject: Re: Fragmentation-related security issues > >> > >> Hi Dan, > >> > >> As you rightly reminded, the current specification permits PTB<1280 > for > >> a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids > it > >> for an IPv6 DST. > >> > >> Rather than changing this, what about clarifying that a host SHOULD > >> treat a received PTB>1280 as: > >> - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 = of > >> RFC6147) > > > > That only helps in half of the RFC6144 scenarios, where the IPv6 > > host is behind the translator (e.g., "Scenario 1: an IPv6 network to > the > > IPv4 Internet"). It would not help in the other half of the RFC6144 > > scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4: > > an IPv4 network to the IPv6 Internet"). It is RFC6144's Scenario 4 > > where stateless IPv6/IPv4 translators, where the IPv4 network has a > > small MTU, that there is a reliance on the last paragraph of Section > > 5 of RFC2460. >=20 > You are right, refusing PTB<12810 if IPv6 DST was not recognized as > IPv4-embedded would break scenarios 3 and 4. > Will these scenarios be as typical as those where an IPv6-only host > reaches an IPv4-only server is unclear, and even IMHO doubtful. > Yet, I agree they must be considered. >=20 > - One approach would be to REQUIRE that IPv4 networks having IPv6-only > access to the Internet have MTU >=3D 1240 (requiring this ONLY for = these > networks shouldn't be a big deal). Yep. That seems a reasonable statement for an "operational consideration"=20 document to make. It might be reasonable for a NAT64 "operational=20 considerations" document in either BEHAVE or V6OPS. =20 Draft-chen-v6ops-nat64-cpe could be that document; although, as I=20 stated at the microphone in IETF82, draft-chen-v6ops-nat64-cpe needs=20 to more clearly separate itself into the various scenarios for=20 a NAT64 device (that is, if the IPv6 network is "the Internet"=20 (not operated by any one entity) or if the IPv6 network is=20 "a network" (operated by the same entity operating the NAT64). That is the same difference between RFC6144's Scenario 1 and 4.) CC'ing authors of draft-chen-v6ops-nat64-cpe. > - Another, non exclusive, would be that IPv4-embedded addresses of = such > networks would be REQUIRED to have a specific format. (A V octet a la > 4rd-U, instead of the u octet of RFC6052, could for instance do the > job). RFC6052 didn't define the "u" octet; rather, RFC6052 is merely=20 preserving the "u" bit's meaning as originally defined in RFC4291. -d > RD >=20 >=20 >=20 > > > > -d > > > >> - an ERROR otherwise. > >> > >> This would at least dissuade from tolerating IPv6 paths with PMTU < > >> 1280. > >> > >> RD > >> > >> > >> > >> Le 2012-01-03 =E0 21:43, Dan Wing a =E9crit : > >>>> ... > >>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >>>> ... > >>>> On 2012-01-04 08:02, Dan Wing wrote: > >>>>> ... > >>>>> So, I don't think we can just wish away packet-too-big < 1280. > >>>> > >>>> Sadly, that seems to be true unless we make a much more radical > >> change, > >>>> because of translators. > >>> > >>> Or, we declare a new restriction that translators are not expected > to > >>> work if the IPv4 network has an MTU less than 1260 = (1260=3D1280-20, > >>> because IPv6 header is 20B bigger than IPv4 header). I don't know > if > >> there > >>> is consensus for such a restriction. To date, both RFC2765 and > >> RFC6145 > >>> avoided such a restriction. However, if there are widespread IPv6 > >>> host implementations or firewalls that erroneously filter or = ignore > >>> ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to > >>> accept that restriction, and modify their IPv4 networks to have > >>> MTU>=3D1260. Such IPv4 network modifications would add to further > >>> pain to IPv6 coexistence. MTU research by Ben Stasiewicz and > >>> Matthew Luckie (WAND), published and presented at RIPE and > >>> other conferences, shows a 2-3% failure rate to various popular > >>> web sites. They did additional testing during World IPv6 Day, > >>> but I haven't dug into those results yet. > >>> > >>> -d > >>> > >>> > >>> = ------------------------------------------------------------------- > - > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 > >>> = ------------------------------------------------------------------- > - > > From brian.e.carpenter@gmail.com Wed Jan 4 18:55:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D97221F85BD for ; Wed, 4 Jan 2012 18:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+-Jfd746P5S for ; Wed, 4 Jan 2012 18:55:15 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5828421F85B6 for ; Wed, 4 Jan 2012 18:55:15 -0800 (PST) Received: by eekc14 with SMTP id c14so48065eek.31 for ; Wed, 04 Jan 2012 18:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mZkp0LwNz+R2B29CCNiIFypu80tUZqt6i3m/UlVhQPs=; b=IOEi5GbxT/Fx2VRlM7IGvyyNQ0LZHyCgZvJufSZnfaxI2bG5iT2YGaGTT+7AoJe/SJ MdsUXrcq4ofn9/Ui0QFL7DjgxbmI4ZA/h6U+io6nE2bXEHgCgRiQKdRGomU/xKDm6KR3 tLtcM0hq0TTNgSxmjo4HNVfxOv5ZUTmYwMYKE= Received: by 10.213.5.1 with SMTP id 1mr135017ebt.70.1325732114533; Wed, 04 Jan 2012 18:55:14 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id a60sm227826564eeb.4.2012.01.04.18.55.11 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 18:55:14 -0800 (PST) Message-ID: <4F05110A.40108@gmail.com> Date: Thu, 05 Jan 2012 15:55:06 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Fragmentation-related security issues References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 02:55:16 -0000 On 2012-01-05 11:50, Templin, Fred L wrote: > > >> -----Original Message----- >> From: Fernando Gont [mailto:fgont@si6networks.com] >> Sent: Wednesday, January 04, 2012 2:22 PM >> To: Templin, Fred L >> Cc: Brian E Carpenter; ipv6@ietf.org >> Subject: Re: Fragmentation-related security issues >> >> On 01/04/2012 07:06 PM, Templin, Fred L wrote: >>>> I see no reason to expect that PMTUD will be more reliable for >>>> IPv6 than for IPv4. >>> I think a lot is now hinging on the assumption that >>> PMTUD for IPv6 works. Unlike the situation for IPv4, >>> I see no reason to expect that PMTUD for IPv6 will >>> be unreliable. >> It has been found to break, already -- as a result of firewalls >> filtering ICMPv6 messages, are some intermediate systems with >> inappropriate rate limiting for all ICMPv6 traffic. > > If IPv6 PMTUD breaks, it is due to violations of the specs. > If IPv6 PMTUD breaks, then we are lost - time to give up > and design a different protocol? The point is that paranoid firewalls will turn this into an arms race - if they are paranoid enough to block ICMP PTB, which apparently many are, why wouldn't they block any other signalling mechanism - especially a new one? That's why RFC 4821 describes MTU probing hidden in the transport layer, where hopefully firewalls would let it be. You will probably look in vain for widely deployed versions of RFC 4821. Brian From bashi.ietf@gmail.com Wed Jan 4 20:13:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5021F858E for ; Wed, 4 Jan 2012 20:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PP8FLzcrr++o for ; Wed, 4 Jan 2012 20:13:59 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9609021F857D for ; Wed, 4 Jan 2012 20:13:58 -0800 (PST) Received: by werb14 with SMTP id b14so94157wer.31 for ; Wed, 04 Jan 2012 20:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZTvqyxryRGp4juCIUlhJCI4Kq/2KN8Z7zmcSWDczy6Y=; b=l9E1O/v6JU4PeHLFP5sRKtjRWoKvZqxvcAzNU4fS9/4wzV8vvxh1/Nl+2j2z9OTheV 7fQZp0R/J3oBfllUfgjx7mLHCMzhmhGWCEwg1ztsvomlTZvFJbL7opJe/lYe1Y+/Cuk0 AtjQPgq0tKugyrz59LLRtyCJHRzrdLHVsG6NY= MIME-Version: 1.0 Received: by 10.216.136.23 with SMTP id v23mr344174wei.48.1325736837840; Wed, 04 Jan 2012 20:13:57 -0800 (PST) Received: by 10.180.105.202 with HTTP; Wed, 4 Jan 2012 20:13:57 -0800 (PST) Date: Thu, 5 Jan 2012 13:13:57 +0900 Message-ID: Subject: ND Proxy and LinkLocal Unicast Packets From: HIROKI ISHIBASHI To: ipv6@ietf.org Content-Type: multipart/alternative; boundary=0016e6deddfd48fe8004b5c02925 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 04:13:59 -0000 --0016e6deddfd48fe8004b5c02925 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have a question on ND proxy with packet destined to a link-local address such as TCP, Ping, etc. Within the context of RFC4389, I am expected to forward/proxy those link-local packets? Thank you in advance. -- Hiroki Ishibashi --0016e6deddfd48fe8004b5c02925 Content-Type: text/html; charset=ISO-8859-1 Hi All,

I have a question on ND proxy with packet destined to a link-local address such as TCP, Ping, etc.
Within the context of RFC4389, I am expected to forward/proxy those link-local packets?

Thank you in advance.
--
Hiroki Ishibashi

--0016e6deddfd48fe8004b5c02925-- From fweimer@bfk.de Thu Jan 5 01:32:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060F821F860E for ; Thu, 5 Jan 2012 01:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.809 X-Spam-Level: X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjDU0irIf9t3 for ; Thu, 5 Jan 2012 01:32:53 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4394B21F85A6 for ; Thu, 5 Jan 2012 01:32:53 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rijgo-0000Fr-QD; Thu, 05 Jan 2012 09:32:50 +0000 Received: by bfk.de with local id 1Rijgo-0004Q4-L2; Thu, 05 Jan 2012 09:32:50 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <4F028C42.1020702@si6networks.com> <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> <4F03BC4F.3020801@si6networks.com> Date: Thu, 05 Jan 2012 09:32:50 +0000 In-Reply-To: <4F03BC4F.3020801@si6networks.com> (Fernando Gont's message of "Tue, 03 Jan 2012 23:41:19 -0300") Message-ID: <82pqeyjxz1.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:32:54 -0000 * Fernando Gont: > b) Processing of atomic fragments as non-fragmented traffic. Is this even possible? The presence of an additional extension header necessarily triggers additional packet processing, doesn't it? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Thu Jan 5 01:41:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C495021F8749 for ; Thu, 5 Jan 2012 01:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUyF20TjOqtt for ; Thu, 5 Jan 2012 01:41:01 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id E0C4221F86E3 for ; Thu, 5 Jan 2012 01:41:00 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rijoh-0000qO-P7; Thu, 05 Jan 2012 09:40:59 +0000 Received: by bfk.de with local id 1Rijoh-0001Z6-K6; Thu, 05 Jan 2012 09:40:59 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <82ehvfnakx.fsf@mid.bfk.de> <4F048DD2.9050107@si6networks.com> Date: Thu, 05 Jan 2012 09:40:59 +0000 In-Reply-To: <4F048DD2.9050107@si6networks.com> (Fernando Gont's message of "Wed, 04 Jan 2012 14:35:14 -0300") Message-ID: <82lipmjxlg.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Bjoern A. Zeeb" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 09:41:01 -0000 * Fernando Gont: > On 01/04/2012 05:19 AM, Florian Weimer wrote: >>> Why should you drop in this case, when it's trivial to process these >>> fragments safely, with no side effects?? >>=20 >> Do we really know that adding a fragment header to all outgoing packets >> does not cause them to be rejected?=20 > > Are you arguing that IPv6 fragmentation does no work at all, or what? I fear that it might work as well as in IPv4, that is, you can only get there with some effort, and for some nodes, it will never work. >> Could this be deployed at large DNS servers in a risk-free fashion, >> for instance? > > What's the specific question you're asking, and what is your concern, > specifically? If DNS servers started sending either atomic fragments or fragmented responses today (i.e., all generated packets carry an IPv6 extension header), would these servers become unreachable for some clients? (I think we have to assume the answer is "yes".) IPv4 is different in this regard because clients can opt out from fragmented responses by requesting 512 byte responses (even if it's technically a DNS protocol violation). This is just not possible with IPv6---unless the server keeps per-client state, which is a non-starter for large DNS server deployments. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Thu Jan 5 02:10:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B08B21F8661 for ; Thu, 5 Jan 2012 02:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg1tfVKp++3I for ; Thu, 5 Jan 2012 02:10:20 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4864221F86C5 for ; Thu, 5 Jan 2012 02:10:18 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RikGp-0002co-HW; Thu, 05 Jan 2012 10:10:03 +0000 Received: by bfk.de with local id 1RikGo-0002Qi-Vd; Thu, 05 Jan 2012 10:10:03 +0000 From: Florian Weimer To: "Manfredi\, Albert E" Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> <01f701ccca58$4b7bd040$e27370c0$@com> <4581455F-282E-42E6-B328-CEB06620C844@free.fr> <043801cccafb$f754beb0$e5fe3c10$@com> Date: Thu, 05 Jan 2012 10:10:02 +0000 In-Reply-To: (Albert E. Manfredi's message of "Wed, 4 Jan 2012 16:37:23 -0600") Message-ID: <828vlmjw91.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:10:31 -0000 * Albert E. Manfredi: > The minimum MTU for IPv4 is 68 bytes. Similarly, in IPv6, PMTU > *should* be allowed to be as small as 40 bytes + 8 bytes for the > fragmentation header + any more required by other options, as > determined by the source host. RFC 791 does indeed say that, but some of us have been working on pushing the IPv4 MTU to some saner value, above 500-something bytes. Many implementations follow that now. > I know RFC 2460 doesn't read this way, but I believe this issue could > be resolved by going back to what RFC 791 really said. Supporting small fragments has high hidden costs. Some of them are addressed by the larger fragment ID in IPv6, but not all of them. There is still no way to authenticate an incoming ICMPv6 PTB message, so you have to be very conservative when processing them. Fragmenting down to 48 bytes is certainly not a good idea (and the current specs don't permit that, anyway). --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From sthaug@nethelp.no Thu Jan 5 02:26:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8784321F87F3 for ; Thu, 5 Jan 2012 02:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLmsezIF-eUT for ; Thu, 5 Jan 2012 02:26:35 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 89B1E21F87F1 for ; Thu, 5 Jan 2012 02:26:34 -0800 (PST) Received: (qmail 51564 invoked from network); 5 Jan 2012 10:26:31 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Jan 2012 10:26:31 -0000 Date: Thu, 05 Jan 2012 11:26:31 +0100 (CET) Message-Id: <20120105.112631.74700244.sthaug@nethelp.no> To: fweimer@bfk.de Subject: Re: Fragmentation-related security issues From: sthaug@nethelp.no In-Reply-To: <82lipmjxlg.fsf@mid.bfk.de> References: <82ehvfnakx.fsf@mid.bfk.de> <4F048DD2.9050107@si6networks.com> <82lipmjxlg.fsf@mid.bfk.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, bzeeb-lists@lists.zabbadoz.net X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:26:35 -0000 > If DNS servers started sending either atomic fragments or fragmented > responses today (i.e., all generated packets carry an IPv6 extension > header), would these servers become unreachable for some clients? > (I think we have to assume the answer is "yes".) The answer is clearly yes, since (for instance) FreeBSD 7.4 with ipfw will drop such packets. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From sthaug@nethelp.no Thu Jan 5 02:32:30 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B6021F85E0 for ; Thu, 5 Jan 2012 02:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m56aXI7dkPY for ; Thu, 5 Jan 2012 02:32:29 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 4899521F85D8 for ; Thu, 5 Jan 2012 02:32:29 -0800 (PST) Received: (qmail 51723 invoked from network); 5 Jan 2012 10:32:28 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 5 Jan 2012 10:32:28 -0000 Date: Thu, 05 Jan 2012 11:32:28 +0100 (CET) Message-Id: <20120105.113228.41680938.sthaug@nethelp.no> To: fweimer@bfk.de Subject: Re: Fragmentation-related security issues From: sthaug@nethelp.no In-Reply-To: <20120105.112631.74700244.sthaug@nethelp.no> References: <4F048DD2.9050107@si6networks.com> <82lipmjxlg.fsf@mid.bfk.de> <20120105.112631.74700244.sthaug@nethelp.no> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: bzeeb-lists@lists.zabbadoz.net, ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:32:30 -0000 > > If DNS servers started sending either atomic fragments or fragmented > > responses today (i.e., all generated packets carry an IPv6 extension > > header), would these servers become unreachable for some clients? > > (I think we have to assume the answer is "yes".) > > The answer is clearly yes, since (for instance) FreeBSD 7.4 with > ipfw will drop such packets. Atomic fragments, that is. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fweimer@bfk.de Thu Jan 5 02:45:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78021F865C for ; Thu, 5 Jan 2012 02:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYHqoUFZCnKw for ; Thu, 5 Jan 2012 02:45:08 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id AE58A21F8655 for ; Thu, 5 Jan 2012 02:45:08 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rikok-0004uC-43; Thu, 05 Jan 2012 10:45:06 +0000 Received: by bfk.de with local id 1Rikok-0004Vm-18; Thu, 05 Jan 2012 10:45:06 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <82sjjxqisl.fsf@mid.bfk.de> <4F036A8A.9000806@si6networks.com> Date: Thu, 05 Jan 2012 10:45:06 +0000 In-Reply-To: <4F036A8A.9000806@si6networks.com> (Fernando Gont's message of "Tue, 03 Jan 2012 17:52:26 -0300") Message-ID: <82obuiig25.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 10:45:09 -0000 * Fernando Gont: > In that case, you're not required to split your packets into fragments > smaller or equal to 1280 bytes, but *are* required to react by including > a Fragment Header in subsequent packets. And the only way to achieve that reliably in certain existing deployments appears to be to send a fragment header unconditionally. (And with increasing IPv6 adoption, this will be only option for every large DNS operator---right now, PMTUD in the IPv6 stack appears to work because the number of clients is small compared to the size of the destination cache in the servers.) Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might be others, of course). Not sending them breaks important transition technology. >> Without the API change in draft-andrews-6man-force-fragmentation, it is >> flat out impossible to server IPv6 traffic in a stateless fashion. The >> stack is required to keep a per-destination cache which records the >> necessity of a fragment extension header, even if the application never >> sends any packets larger than 1280 bytes. > > The stack is required to have a Destination Cache, anyway. Could you elaborate on that? For some operators, the ability to serve stateless protocols statelessly over IPv6 is quite important. I'm not aware of any fundamental requirement for per-destination bookkeeping in IPv6 nodes. >>> Sorry, I cannot see why some packets would require going through a >>> translator, while others wouldn't. >>=20 >> The joy of packet switching. 8-) > > If a packet is actually destined to the IPv4 world (and hence needs to > go through a translator), it will need to cross one translator, or > another... but *some* translator. Couldn't it be translated back to IPv6? Then there could be an IPv6-only path between sender and recipient. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From bzeeb-lists@lists.zabbadoz.net Thu Jan 5 03:25:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC6C21F875B for ; Thu, 5 Jan 2012 03:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Tr6-U55t8O for ; Thu, 5 Jan 2012 03:25:44 -0800 (PST) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id BD07721F86B2 for ; Thu, 5 Jan 2012 03:25:44 -0800 (PST) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 088DF25D37C3; Thu, 5 Jan 2012 11:25:42 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 35147BD8858; Thu, 5 Jan 2012 11:25:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 92FBc4QVBUPE; Thu, 5 Jan 2012 11:25:40 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 271A1BD885A; Thu, 5 Jan 2012 11:25:39 +0000 (UTC) Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <82pqeyjxz1.fsf@mid.bfk.de> Date: Thu, 5 Jan 2012 11:25:38 +0000 Content-Transfer-Encoding: 7bit Message-Id: <1B4D5CF3-AA0F-4AC2-A545-59AD9985B4F8@lists.zabbadoz.net> References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <4F028C42.1020702@si6networks.com> <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> <4F03BC4F.3020801@si6networks.com> <82pqeyjxz1.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1084) Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 11:25:45 -0000 On 5. Jan 2012, at 09:32 , Florian Weimer wrote: > * Fernando Gont: > >> b) Processing of atomic fragments as non-fragmented traffic. > > Is this even possible? The presence of an additional extension header > necessarily triggers additional packet processing, doesn't it? What he means is remove the fragment header in this case without any other fragment code processing and continue handling the packet as if you'd have received it without the ext hdr. That this is still an expensive operation for a silly packet does not seem to trickle down so avoiding these cases whenever possible should be the rule. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From jared@puck.nether.net Thu Jan 5 04:42:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24AF21F87F1 for ; Thu, 5 Jan 2012 04:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuFovZOkW6gS for ; Thu, 5 Jan 2012 04:41:59 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id C14F421F87EB for ; Thu, 5 Jan 2012 04:41:59 -0800 (PST) Received: from [172.17.91.138] ([12.238.77.194]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q05CfD2o002533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jan 2012 07:41:13 -0500 Subject: Re: Fragmentation-related security issues Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <4F05110A.40108@gmail.com> Date: Thu, 5 Jan 2012 07:41:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 05 Jan 2012 07:41:13 -0500 (EST) Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 12:42:00 -0000 On Jan 4, 2012, at 9:55 PM, Brian E Carpenter wrote: > The point is that paranoid firewalls will turn this into an > arms race - if they are paranoid enough to block ICMP PTB, > which apparently many are, why wouldn't they block any other > signalling mechanism - especially a new one? >=20 > That's why RFC 4821 describes MTU probing hidden in the transport > layer, where hopefully firewalls would let it be. You will > probably look in vain for widely deployed versions of RFC 4821. We will not win a discussion with people who fail to understand how the technology actually works vs their concept of it. I'm waiting for the likely millions of users to have trouble when dns more often requires TCP transport for some queries/responses. I see the side-effects of this in my name server logs daily for people not doing EDNS and who can't handle udp packets past 512. Jan 5 07:35:55 puck named[26179]: fldsmtpe02.verizon.com/A: changed = rcode: setting NOEDNS flag in adb cache for '192.76.85.133#53' We can't protect people from doing something wrong/outside spec, nor do I feel we should spend a lot of effort catering to solve their problems for them. Just because my prius can go off-road doesn't mean it's the intended operation nor is covered when I abuse it. Same goes here, vendors and carriers need to tell customers their security technique is unsupported and will break things. It's not the role of the carrier to solve all the problems for the customer who does something weird in this case, unless they're the one creating the problem by using 1000 mtu links w/ IPv6. Any vendor that supports setting the mtu under 1280 on IPv6 should face a reality check sooner vs later. - Jared= From despres.remi@laposte.net Thu Jan 5 09:03:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3445921F85BD for ; Thu, 5 Jan 2012 09:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRYCBos8-yaM for ; Thu, 5 Jan 2012 09:03:00 -0800 (PST) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by ietfa.amsl.com (Postfix) with ESMTP id 686CE21F85AF for ; Thu, 5 Jan 2012 09:02:59 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 8F90B7000044; Thu, 5 Jan 2012 18:02:58 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2108.sfr.fr (SMTP Server) with ESMTP id 4E2487000102; Thu, 5 Jan 2012 18:02:53 +0100 (CET) X-SFR-UUID: 20120105170254320.4E2487000102@msfrf2108.sfr.fr Subject: Re: Atomic fragments: converging on something? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F04AA46.6090806@si6networks.com> Date: Thu, 5 Jan 2012 18:02:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0359C3D2-3011-4676-A76A-B3244E151756@laposte.net> References: <4F038BD2.6080805@si6networks.com> <4F04AA46.6090806@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Timothy Hartrick , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:03:01 -0000 Hi Fernando, Full agreement on the substance of your draft, and support for an RFC = based on it. However, I believe it should rather be a BCP than a Standard-track RFC. (I don't see any need to standardize anything beyond what already = exists.) Regards, RD Le 2012-01-04 =E0 20:36, Fernando Gont a =E9crit : > On 01/04/2012 02:51 PM, Timothy Hartrick wrote: >> Folks, >>=20 >> The posting of draft-gont-6man-ipv6-atomic-fragments-00.txt = triggered >> some (unintended) discussion about the usefulness/legitimacy of = IPv6 >> "atomic fragments" (IPv6 packets that contain a Fragmentation = Header, >> but that have the "More Fragments" bit set to zero). >>=20 >>=20 >> Just to clarify what you mean by an atomic fragment; you mean = fragments >> with an offset of 0 and the "More Fragments" flag set to zero. That = is, >> this is the beginning and there is no more. >=20 > Yes, exactly. (Sorry for the confusion! -- 24-hours working on code > without any sleep (literally) did have their effect on me, it seems... = :-( ) >=20 >=20 >> My understanding is that is quite clear that such packets have = been >> found in the wild and that a number of things would break if they = were >> blocked or banned. >>=20 >>=20 >> They are essential to translation systems. Firewalls that block them >> are broken since "atomic fragments" represent no security risk and = are a >> legal part of the protocol. >=20 > That's my take, too. >=20 >=20 >=20 >> That said, I'd like some feedback on the actual proposal in >> draft-gont-6man-ipv6-atomic-fragments-00.txt: process the = aforementioned >> "atomic fragments" as if they were non-fragmented packets. This = would >> basically eliminate all the security issues and problems normally >> associated with framgentation, while still allowing their = legitimate >> use. >>=20 >> On the one hand I would prefer that this document not be necessary.=20= >> That is, treating "atomic fragments" as not being fragmented at all = is >> the way that any competent software engineer would treat them. The = idea >> of allocating reassembly state and timers for datagrams of this sort = and >> then executing anything like the normal reassembly logic on them is >> absurd. It is difficult to imagine that there are implementations = that >> would do so. >=20 > Test some of them, and you'll see. :-) >=20 >=20 >> That said, if we need to spell that out in great and gory detail to = get >> implementors to do the obvious thing, then I guess we need to. I >> grudgingly support the proposal to document how implementations = should >> treat "atomic fragments". >=20 > Thanks, for your support. My experience with this sort of corner cases > is that unless you explicitly say what should be done, you cannot = assume > that implementers will follow your own logic (even if it's supposed to > be obvious). >=20 > Sometimes it takes time and discussion (such as that in this thread) = for > us (protocol types :-) ) to converge on something.. so it shouldn't be > surprising that someone working on tons of patches doesn't spend some > time trying to get every detail right. >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Fred.L.Templin@boeing.com Thu Jan 5 09:33:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A1921F876F for ; Thu, 5 Jan 2012 09:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6NIvdcABcsB for ; Thu, 5 Jan 2012 09:33:42 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAA521F8790 for ; Thu, 5 Jan 2012 09:33:42 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q05HXUZO012358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jan 2012 09:33:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q05HXeOV000387; Thu, 5 Jan 2012 11:33:40 -0600 (CST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q05HXWip000190 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 5 Jan 2012 11:33:35 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Thu, 5 Jan 2012 09:33:24 -0800 From: "Templin, Fred L" To: Brian E Carpenter Date: Thu, 5 Jan 2012 09:33:23 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczLVXcBCPpzhLrxS+2DlKhZMTk5NwAeZqgw Message-ID: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> In-Reply-To: <4F05110A.40108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:33:43 -0000 Hi Brian,=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Wednesday, January 04, 2012 6:55 PM > To: Templin, Fred L > Cc: Fernando Gont; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 2012-01-05 11:50, Templin, Fred L wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Fernando Gont [mailto:fgont@si6networks.com]=20 > >> Sent: Wednesday, January 04, 2012 2:22 PM > >> To: Templin, Fred L > >> Cc: Brian E Carpenter; ipv6@ietf.org > >> Subject: Re: Fragmentation-related security issues > >> > >> On 01/04/2012 07:06 PM, Templin, Fred L wrote: > >>>> I see no reason to expect that PMTUD will be more reliable for > >>>> IPv6 than for IPv4. > >>> I think a lot is now hinging on the assumption that > >>> PMTUD for IPv6 works. Unlike the situation for IPv4, > >>> I see no reason to expect that PMTUD for IPv6 will > >>> be unreliable. > >> It has been found to break, already -- as a result of firewalls > >> filtering ICMPv6 messages, are some intermediate systems with > >> inappropriate rate limiting for all ICMPv6 traffic. > >=20 > > If IPv6 PMTUD breaks, it is due to violations of the specs. > > If IPv6 PMTUD breaks, then we are lost - time to give up > > and design a different protocol? >=20 > The point is that paranoid firewalls will turn this into an > arms race - if they are paranoid enough to block ICMP PTB, > which apparently many are, why wouldn't they block any other > signalling mechanism - especially a new one? SEAL provides a new signalling mechanism called "SCMP" which is intended to traverse firewalls that might block ICMP messages. SCMP messages include a message signature that the source node can use to determine whether the packet-in-error corresponds to a packet the node actually sent. Under what reasonable circumstances could even a paranoid firewall block that? > That's why RFC 4821 describes MTU probing hidden in the transport > layer, where hopefully firewalls would let it be. You will > probably look in vain for widely deployed versions of RFC 4821. Thanks for mentioning RFC4821 - it occurred to me last nite that I had mis-spoken and that RFC4821 is advisable even if the network is making a best effort to return ICMPs. I think this is fairly well captured in Section 5.6 of RFC6434. However, the use or non-use of RFC4821 does not excuse the network from making a best effort to return the required *CMPs. Fred fred.l.templin@boeing.com > Brian > = From Tina.Tsou.Zouting@huawei.com Thu Jan 5 09:59:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A2E21F87F6 for ; Thu, 5 Jan 2012 09:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdG6uUjgT05m for ; Thu, 5 Jan 2012 09:59:09 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [58.251.152.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB8921F87ED for ; Thu, 5 Jan 2012 09:59:09 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXC00KTZ7A9U4@szxga03-in.huawei.com> for ipv6@ietf.org; Fri, 06 Jan 2012 01:58:57 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXC00FWK7A92L@szxga03-in.huawei.com> for ipv6@ietf.org; Fri, 06 Jan 2012 01:58:57 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGD29444; Fri, 06 Jan 2012 01:58:53 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 06 Jan 2012 01:58:52 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.37]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 06 Jan 2012 01:58:33 +0800 Date: Thu, 05 Jan 2012 17:58:33 +0000 From: Tina TSOU Subject: Re: Fragmentation-related security issues In-reply-to: <82obuiig25.fsf@mid.bfk.de> To: Florian Weimer Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: Fragmentation-related security issues Thread-index: AQHMy5cWgfBXnz8Ip0iGobOPl6FwsZX+EBlo X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <82sjjxqisl.fsf@mid.bfk.de> <4F036A8A.9000806@si6networks.com> <82obuiig25.fsf@mid.bfk.de> Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:59:10 -0000 Sent from my iPad On Jan 5, 2012, at 2:45 AM, "Florian Weimer" wrote: > * Fernando Gont: >=20 >> In that case, you're not required to split your packets into fragments >> smaller or equal to 1280 bytes, but *are* required to react by including >> a Fragment Header in subsequent packets. >=20 > And the only way to achieve that reliably in certain existing > deployments appears to be to send a fragment header unconditionally. > (And with increasing IPv6 adoption, this will be only option for every > large DNS operator---right now, PMTUD in the IPv6 stack appears to work > because the number of clients is small compared to the size of the > destination cache in the servers.) >=20 > Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might > be others, of course). Not sending them breaks important transition > technology. >=20 >>> Without the API change in draft-andrews-6man-force-fragmentation, it is >>> flat out impossible to server IPv6 traffic in a stateless fashion. The >>> stack is required to keep a per-destination cache which records the >>> necessity of a fragment extension header, even if the application never >>> sends any packets larger than 1280 bytes. >>=20 >> The stack is required to have a Destination Cache, anyway. >=20 > Could you elaborate on that? For some operators, the ability to serve > stateless protocols statelessly over IPv6 is quite important. I'm not > aware of any fundamental requirement for per-destination bookkeeping in > IPv6 nodes. >=20 >>>> Sorry, I cannot see why some packets would require going through a >>>> translator, while others wouldn't. >>>=20 >>> The joy of packet switching. 8-) >>=20 >> If a packet is actually destined to the IPv4 world (and hence needs to >> go through a translator), it will need to cross one translator, or >> another... but *some* translator. >=20 > Couldn't it be translated back to IPv6? Then there could be an > IPv6-only path between sender and recipient. I'm deploying it. It's hard to find. >=20 > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From shemant@cisco.com Thu Jan 5 12:06:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919F821F88B4 for ; Thu, 5 Jan 2012 12:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGTRjhRNOFpv for ; Thu, 5 Jan 2012 12:06:47 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1F821F88B2 for ; Thu, 5 Jan 2012 12:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2718; q=dns/txt; s=iport; t=1325794007; x=1327003607; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=0BAkNp9ZTgmqbtb0OZC0drmi7qxm7v0Crjem7P8b6Do=; b=gcUvwrvk48OXHSvwygNT/34Ws3XTSSWmaw+dZJsWb9ZpxHjb7skyNAZ9 FPgEb5DMs5xs8kI62k+clYn5LKGHiwhaVEMD1Pkkm+BhPAx5B6vwLtobV ugcOz5W0ZJUNzQv6Gof8glURjT71oeChqRdON01RcxWJ5BNQN8zurZuoj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFABUCBk+tJV2Y/2dsb2JhbABCggWDCqZngQiBBYFyAQEBBBIBEA0EQw4GAQgRBAEBAwIGBhcBAgIDAUQHAQEFBAEEEwganjyBJgGMXZFDgS+HSIIEM2MEiDmfIQ X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; d="scan'208";a="48999926" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 05 Jan 2012 20:06:46 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q05K6jTN005607 for ; Thu, 5 Jan 2012 20:06:46 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 14:06:45 -0600 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: FW: New Version Notification for draft-hsingh-6man-enhanced-dad-04.txt Date: Thu, 5 Jan 2012 14:06:44 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C303A852F5@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-hsingh-6man-enhanced-dad-04.txt Thread-Index: AczL5TdWhzICNTlwTnW7khF6EyCZ/AAABHyw From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 05 Jan 2012 20:06:45.0949 (UTC) FILETIME=[8CF186D0:01CCCBE5] X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 20:06:48 -0000 Nm1hbiBmb2xrcywNCg0KQSBuZXcgdmVyc2lvbiBoYXMgYmVlbiBwb3N0ZWQgdG9kYXkuICAgVGhp cyB2ZXJzaW9uIGhhcyBhIG1pbm9yIGVkaXRvcmlhbCBjaGFuZ2UgaW4gdGhlIEludHJvZHVjdGlv biBzZWN0aW9uLiAgUGxlYXNlIHNlZSB0aGUgQ2hhbmdlLWxvZyBhcHBlbmRpeCBmb3IgY2hhbmdl cy4gIENoYWlycywgY291bGQgeW91IHBsZWFzZSBzZW5kIG91dCBhIGNhbGwgdG8gdGhlIG1haWxl ciB3aGVuIHlvdSBnZXQgYSBjaGFuY2UgZm9yIHZvdGUgb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudC4NCg0KVGhhbmtzLA0KDQpIZW1hbnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAxMiAzOjA0IFBNDQpUbzog SGVtYW50IFNpbmdoIChzaGVtYW50KQ0KQ2M6IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsg V2VzIEJlZWJlZSAod2JlZWJlZSk7IEhlbWFudCBTaW5naCAoc2hlbWFudCk7IGRhcnRAZXMubmV0 OyB3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tOyBSYWppdiBBc2F0aSAocmFqaXZhKQ0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oc2luZ2gtNm1hbi1lbmhhbmNl ZC1kYWQtMDQudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1oc2luZ2gtNm1hbi1l bmhhbmNlZC1kYWQtMDQudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSGVt YW50IFNpbmdoIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1oc2luZ2gtNm1hbi1lbmhhbmNlZC1kYWQNClJldmlzaW9uOgkgMDQNClRpdGxlOgkJ IEVuaGFuY2VkIER1cGxpY2F0ZSBBZGRyZXNzIERldGVjdGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIw MTItMDEtMDUNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2Vz OiAxMg0KDQpBYnN0cmFjdDoNCiAgIEFwcGVuZGl4IEEgb2YgdGhlIElQdjYgRHVwbGljYXRlIEFk ZHJlc3MgRGV0ZWN0aW9uIChEQUQpIGRvY3VtZW50IGluDQogICBSRkMgNDg2MiBkaXNjdXNzZXMg TG9vcGJhY2sgU3VwcHJlc3Npb24gYW5kIERBRC4gIEhvd2V2ZXIsIFJGQyA0ODYyDQogICBkb2Vz IG5vdCBzZXR0bGUgb24gb25lIHNwZWNpZmljIGF1dG9tYXRlZCBtZWFucyB0byBkZXRlY3QgbG9v cGJhY2sgb2YNCiAgIE5laWdoYm9yIERpc2NvdmVyeSAoTkQgb2YgUkZDIDQ4NjEpIG1lc3NhZ2Vz IHVzZWQgYnkgREFELiAgU2V2ZXJhbA0KICAgc2VydmljZSBwcm92aWRlciBjb21tdW5pdGllcyBo YXZlIGV4cHJlc3NlZCBhIG5lZWQgZm9yIGF1dG9tYXRlZA0KICAgZGV0ZWN0aW9uIG9mIGxvb3Bl ZCBiYWNrZWQgTkQgbWVzc2FnZXMgdXNlZCBieSBEQUQuICBUaGlzIGRvY3VtZW50DQogICBpbmNs dWRlcyBtaXRpZ2F0aW9uIHRlY2huaXF1ZXMgYW5kIHRoZW4gb3V0bGluZXMgdGhlIEVuaGFuY2Vk IERBRA0KICAgYWxnb3JpdGhtIHRvIGF1dG9tYXRlIGRldGVjdGlvbiBvZiBsb29wZWQgYmFjayBJ UHY2IE5EIG1lc3NhZ2VzIHVzZWQNCiAgIGJ5IERBRC4gIEZvciBuZXR3b3JrIGxvb3BiYWNrIHRl c3RzLCB0aGUgRW5oYW5jZWQgREFEIGFsZ29yaXRobQ0KICAgYWxsb3dzIElQdjYgdG8gc2VsZi1o ZWFsIGFmdGVyIGEgbG9vcGJhY2sgaXMgcGxhY2VkIGFuZCByZW1vdmVkLg0KICAgRnVydGhlciwg Zm9yIGNlcnRhaW4gYWNjZXNzIG5ldHdvcmtzIHRoZSBkb2N1bWVudCBhdXRvbWF0ZXMgcmVzb2x2 aW5nDQogICBhIHNwZWNpZmljIGR1cGxpY2F0ZSBhZGRyZXNzIGNvbmZsaWN0Lg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg== From marka@isc.org Thu Jan 5 15:31:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D14911E807A for ; Thu, 5 Jan 2012 15:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.942, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, SARE_MILLIONSOF=0.315, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6ASCWpd2qj6 for ; Thu, 5 Jan 2012 15:31:32 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2117611E8073 for ; Thu, 5 Jan 2012 15:31:31 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 58A00C9423; Thu, 5 Jan 2012 23:31:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:b8ee:d196:9ec1:4f7c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 09CA3216C6A; Thu, 5 Jan 2012 23:31:17 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 905D51AD4400; Fri, 6 Jan 2012 00:58:50 +1100 (EST) To: Jared Mauch From: Mark Andrews References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> Subject: Re: Fragmentation-related security issues In-reply-to: Your message of "Thu, 05 Jan 2012 07:41:55 CDT." Date: Fri, 06 Jan 2012 00:58:50 +1100 Message-Id: <20120105135850.905D51AD4400@drugs.dv.isc.org> Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 23:31:33 -0000 In message , Jared Mauch writes: > > On Jan 4, 2012, at 9:55 PM, Brian E Carpenter wrote: > > > The point is that paranoid firewalls will turn this into an > > arms race - if they are paranoid enough to block ICMP PTB, > > which apparently many are, why wouldn't they block any other > > signalling mechanism - especially a new one? > > > > That's why RFC 4821 describes MTU probing hidden in the transport > > layer, where hopefully firewalls would let it be. You will > > probably look in vain for widely deployed versions of RFC 4821. > > We will not win a discussion with people who fail to understand how > the technology actually works vs their concept of it. > > I'm waiting for the likely millions of users to have trouble when > dns more often requires TCP transport for some queries/responses. > I see the side-effects of this in my name server logs daily for > people not doing EDNS and who can't handle udp packets past 512. > > Jan 5 07:35:55 puck named[26179]: fldsmtpe02.verizon.com/A: changed rcode: s > etting NOEDNS flag in adb cache for '192.76.85.133#53' That one isn't outside the spec. The server answers EDNS queries, it's just a old (RFC 1035), server. What is outside the spec in silently dropping queries if you see something you don't understand. RFC 1035 has a error code (FORMERR) for that and it should be returned. What is unconscionable, is firewall vendor shipping products in 2012 which don't handle protocol changes from 1999. EDNS is designed to interoperate with RFC 1035 bases servers. Dropping of fragmented packets is slowly disappearing with the deployment of DNSSEC. The DNS get slower and slower and eventually people start complaining. Fixing firewalls that are dropping fragmented packets usually just requires a rule change. > We can't protect people from doing something wrong/outside spec, nor > do I feel we should spend a lot of effort catering to solve their > problems for them. Just because my prius can go off-road doesn't > mean it's the intended operation nor is covered when I abuse it. > > Same goes here, vendors and carriers need to tell customers their > security technique is unsupported and will break things. It's > not the role of the carrier to solve all the problems for the > customer who does something weird in this case, unless they're > the one creating the problem by using 1000 mtu links w/ IPv6. > > Any vendor that supports setting the mtu under 1280 on IPv6 should > face a reality check sooner vs later. > > - Jared > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From fernando.gont.netbook.win@gmail.com Thu Jan 5 17:02:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B3A11E807A for ; Thu, 5 Jan 2012 17:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og6t-bUA+tW7 for ; Thu, 5 Jan 2012 17:02:55 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA3011E8087 for ; Thu, 5 Jan 2012 17:02:52 -0800 (PST) Received: by ggnk5 with SMTP id k5so575598ggn.31 for ; Thu, 05 Jan 2012 17:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Fiq64G1oaxfEbR/PzxaCZ8ww8W2R+1+q752vu3CVsAg=; b=eoXm5YCmAHwr19PUDKMDv7vMpuvRtyxsc5AJnwhnInaKT6cixnRmDD+0A3J9nqnl43 V4XkOWGZhg+aYJtqUK0kZaNGuQU2RFuucDSEZATeAHg3McnkjmjrsWXfe2uniTL8MVmY VyHnTP9n0YDGk+FeXQRF9Yz+FR2kOhfoUUqDI= Received: by 10.101.4.39 with SMTP id g39mr1869725ani.47.1325811771859; Thu, 05 Jan 2012 17:02:51 -0800 (PST) Received: from [192.168.123.102] ([190.48.248.59]) by mx.google.com with ESMTPS id 3sm32708972ank.6.2012.01.05.17.02.48 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 17:02:50 -0800 (PST) Sender: Fernando Gont Message-ID: <4F060631.1070903@gont.com.ar> Date: Thu, 05 Jan 2012 17:21:05 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <82ehvfnakx.fsf@mid.bfk.de> <4F048DD2.9050107@si6networks.com> <82lipmjxlg.fsf@mid.bfk.de> In-Reply-To: <82lipmjxlg.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org, "Bjoern A. Zeeb" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:02:56 -0000 Florian, On 01/05/2012 06:40 AM, Florian Weimer wrote: >>> Do we really know that adding a fragment header to all outgoing packets >>> does not cause them to be rejected? >> >> Are you arguing that IPv6 fragmentation does no work at all, or what? > > I fear that it might work as well as in IPv4, that is, you can only get > there with some effort, and for some nodes, it will never work. But that's an entirely different question. If you're thinking about e.g. banning all fragmentation from IPv6, that's certainly completely unrelated to the two I-D's that I've published on the subject... >>> Could this be deployed at large DNS servers in a risk-free fashion, >>> for instance? >> >> What's the specific question you're asking, and what is your concern, >> specifically? > > If DNS servers started sending either atomic fragments or fragmented > responses today (i.e., all generated packets carry an IPv6 extension > header), would these servers become unreachable for some clients? > (I think we have to assume the answer is "yes".) Because some clients ignore atomic fragments, because fragments would be dropped in the path to the client, or what? Note: I'm interested on the topic, but this one has to do more with Mark Andrews' proposal than with mine. -- Mine is about how to improve the state of affairs of IPv6 fragmentation. Mark's is about increasing its use. > IPv4 is different in this regard because clients can opt out from > fragmented responses by requesting 512 byte responses (even if it's > technically a DNS protocol violation). This is just not possible with > IPv6---unless the server keeps per-client state, which is a non-starter > for large DNS server deployments. Strictly speaking, that's not correct. Requesting 512-byte responses does not necessarily avoid fragmentation. The IPv4 MTU is 68 bytes, not 576. For instance, OpenBSD's imposes a lower limit of 296 (rather than 576 or the like) because such low-MTU technologies exist. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Thu Jan 5 17:03:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A522611E8093 for ; Thu, 5 Jan 2012 17:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkctGHSM0leO for ; Thu, 5 Jan 2012 17:03:04 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 276C111E8091 for ; Thu, 5 Jan 2012 17:03:04 -0800 (PST) Received: by mail-gx0-f172.google.com with SMTP id k5so575598ggn.31 for ; Thu, 05 Jan 2012 17:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=ZU0Z00FJ2z02RB3lwopRMEVAt6R0acrOgIvyo5GyrE4=; b=W0+0MRLfjx3FpLbHEGPq5JsHfSk3GleC6lbE85tzK7HWIub8Wnv1qyc2eWcUu30dkw +FpXjFLf4hIeIii8DYZfg1Yuz4+BiHuOg07HD1lP0zq7VdZhPr9PLaLNMk+jS7t4oikj Q5wZILgE2jG6O+FMxzV7gCwXN0gKoZFW1My+M= Received: by 10.101.208.1 with SMTP id k1mr2016178anq.12.1325811783984; Thu, 05 Jan 2012 17:03:03 -0800 (PST) Received: from [192.168.123.102] ([190.48.248.59]) by mx.google.com with ESMTPS id j16sm27632863anm.9.2012.01.05.17.03.01 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 17:03:03 -0800 (PST) Sender: Fernando Gont Message-ID: <4F06146B.8050200@gont.com.ar> Date: Thu, 05 Jan 2012 18:21:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <4F028C42.1020702@si6networks.com> <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> <4F03BC4F.3020801@si6networks.com> <82pqeyjxz1.fsf@mid.bfk.de> In-Reply-To: <82pqeyjxz1.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:03:04 -0000 On 01/05/2012 06:32 AM, Florian Weimer wrote: >> b) Processing of atomic fragments as non-fragmented traffic. > > Is this even possible? The presence of an additional extension header > necessarily triggers additional packet processing, doesn't it? Well, in your Fragment Header processing routine, the first thing you should do is check whether the Fragment Offset is 0 *and* the M bit is also 0. If that's the case, remove the Fragment Header, fix the Payload Length, and that's it "the fragment has been reassembled". Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Thu Jan 5 17:03:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6AD11E807A for ; Thu, 5 Jan 2012 17:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJOiUBGQaUNS for ; Thu, 5 Jan 2012 17:03:15 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id C4F4411E8098 for ; Thu, 5 Jan 2012 17:03:14 -0800 (PST) Received: from [190.48.248.59] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiyCi-0005cm-3M; Fri, 06 Jan 2012 02:02:44 +0100 Message-ID: <4F05253F.8060705@si6networks.com> Date: Thu, 05 Jan 2012 01:21:19 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Fragmentation-related security issues References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> In-Reply-To: <4F05110A.40108@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:03:15 -0000 On 01/04/2012 11:55 PM, Brian E Carpenter wrote: > That's why RFC 4821 describes MTU probing hidden in the transport > layer, where hopefully firewalls would let it be. You will > probably look in vain for widely deployed versions of RFC 4821. The problem with RFC4821 (assumming the ICMP-free variant) is that it has a longer convergnece time that ICMP-enabled PMTU. That's why people think of RFC4821 as a mechanism for PMTUD blackhole detection rathern than as a repalcement for traditional PMTUD (i.e., you use the transport-layer probes when it looks like tradictional PMTUD is not working (possibly as a result of filtered ICMP error messages)). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fernando.gont.netbook.win@gmail.com Thu Jan 5 17:03:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561C611E80A1 for ; Thu, 5 Jan 2012 17:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GfREbmU4IbD for ; Thu, 5 Jan 2012 17:03:19 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 725A711E809F for ; Thu, 5 Jan 2012 17:03:19 -0800 (PST) Received: by yhjj72 with SMTP id j72so478055yhj.31 for ; Thu, 05 Jan 2012 17:03:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=OzHFZVX/ocMdx2cxM28HSOg0ChOkoInvprQjUoMDcYI=; b=r5eUGDe/QAwaku6lWGnUOywVeiFdxP8jwM3K+L7pX6m5hOIrIkZLij5Xc1ePTt051a /gDL8kF9z9eNJuTRlc3fkOuLf1VpwfhVlNU1g3oIRMvn0P56nUJrFcQt8ly2lt3qSlvf e9bfd4uO4lX7wuUpXU81ZoVzjFj2Fwyrsb3ZE= Received: by 10.236.184.8 with SMTP id r8mr4794478yhm.110.1325811799109; Thu, 05 Jan 2012 17:03:19 -0800 (PST) Received: from [192.168.123.102] ([190.48.248.59]) by mx.google.com with ESMTPS id g12sm12744540ani.17.2012.01.05.17.03.16 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 17:03:18 -0800 (PST) Sender: Fernando Gont Message-ID: <4F062143.600@gont.com.ar> Date: Thu, 05 Jan 2012 19:16:35 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> <01f701ccca58$4b7bd040$e27370c0$@com> <4581455F-282E-42E6-B328-CEB06620C844@free.fr> <043801cccafb$f754beb0$e5fe3c10$@com> <828vlmjw91.fsf@mid.bfk.de> In-Reply-To: <828vlmjw91.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:03:20 -0000 On 01/05/2012 07:10 AM, Florian Weimer wrote: > Supporting small fragments has high hidden costs. Some of them are > addressed by the larger fragment ID in IPv6, but not all of them. There > is still no way to authenticate an incoming ICMPv6 PTB message, so you RFC 5927 is your friend. Check for "progress" on the corresponding connections on which you've received the packet. For UDP, forget it. Actually, the idea of using state (as the PMTU information) with a state-less protocol (such as UDP) should (by itself) raise concerns. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Thu Jan 5 17:03:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8490F11E80A1 for ; Thu, 5 Jan 2012 17:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvJ62lzCkG6w for ; Thu, 5 Jan 2012 17:03:22 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id BA2A611E809D for ; Thu, 5 Jan 2012 17:03:21 -0800 (PST) Received: from [190.48.248.59] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiyCw-0005d0-UJ; Fri, 06 Jan 2012 02:02:59 +0100 Message-ID: <4F0613FA.2060503@si6networks.com> Date: Thu, 05 Jan 2012 18:19:54 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Fragmentation-related security issues References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:03:22 -0000 On 01/05/2012 02:33 PM, Templin, Fred L wrote: > SEAL provides a new signalling mechanism called "SCMP" > which is intended to traverse firewalls that might block > ICMP messages. SCMP messages include a message signature > that the source node can use to determine whether the > packet-in-error corresponds to a packet the node actually > sent. Under what reasonable circumstances could even a > paranoid firewall block that? "SEAL? We're not using it, so let's block it" [Without knowing about SEAL or its packets' syntax] Bottom-line is that unless you're protocol cannot easily be distinguished from some widely-deployed/widely-used protocol, it's probably going to be blocked. That's why e.g. firewall-friendly protocols tend to run over HTTP. P.S.: I'm just the messenger... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Fred.L.Templin@boeing.com Thu Jan 5 17:08:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2521F85B0 for ; Thu, 5 Jan 2012 17:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnJdQUQpVbAS for ; Thu, 5 Jan 2012 17:08:55 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 746F521F859F for ; Thu, 5 Jan 2012 17:08:55 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0619F8b027315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jan 2012 19:09:16 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q0618fUx014474; Thu, 5 Jan 2012 17:08:41 -0800 (PST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0618XW2014379 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 5 Jan 2012 17:08:33 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 5 Jan 2012 17:08:33 -0800 From: "Templin, Fred L" To: Fernando Gont , Brian E Carpenter Date: Thu, 5 Jan 2012 17:08:32 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczMDuzRbWbiF5nUQN24NdKQMWaCuAAADfiQ Message-ID: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> In-Reply-To: <4F05253F.8060705@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:08:56 -0000 Hi Fernando,=20 > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com]=20 > Sent: Wednesday, January 04, 2012 8:21 PM > To: Brian E Carpenter > Cc: Templin, Fred L; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 01/04/2012 11:55 PM, Brian E Carpenter wrote: > > That's why RFC 4821 describes MTU probing hidden in the transport > > layer, where hopefully firewalls would let it be. You will > > probably look in vain for widely deployed versions of RFC 4821. >=20 > The problem with RFC4821 (assumming the ICMP-free variant) is that it > has a longer convergnece time that ICMP-enabled PMTU. RFC4821 works even if there are no ICMPs, but will converge more quickly if there are ICMPs. That is why RFC4821 should be a SHOULD for hosts, and generation of ICMPs should be a MUST for routers. > That's why people think of RFC4821 as a mechanism for PMTUD blackhole > detection rathern than as a repalcement for traditional PMTUD=20 > (i.e., you > use the transport-layer probes when it looks like=20 > tradictional PMTUD is > not working (possibly as a result of filtered ICMP error messages)). The two are complementary. RFC4821 is about the endpoints of communication working together in parallel with the network providing a best-effort service. It's just that sometimes the network best-effort service is not good enough. Fred fred.l.templin@boeing.com > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > = From Fred.L.Templin@boeing.com Thu Jan 5 17:15:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4378621F887E for ; Thu, 5 Jan 2012 17:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYtkAR9L4zzt for ; Thu, 5 Jan 2012 17:15:18 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id B34AE21F8850 for ; Thu, 5 Jan 2012 17:15:18 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q061F49C006350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jan 2012 17:15:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q061F3EY019718; Thu, 5 Jan 2012 17:15:03 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q061EiZD019382 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 5 Jan 2012 17:14:53 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Thu, 5 Jan 2012 17:14:46 -0800 From: "Templin, Fred L" To: Fernando Gont Date: Thu, 5 Jan 2012 17:14:45 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczMDvIN7q+dGd4RTwS4QmfsYGEiKQAAMjKw Message-ID: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F0613FA.2060503@si6networks.com> In-Reply-To: <4F0613FA.2060503@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:15:19 -0000 Hi Fernando,=20 > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com]=20 > Sent: Thursday, January 05, 2012 1:20 PM > To: Templin, Fred L > Cc: Brian E Carpenter; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 01/05/2012 02:33 PM, Templin, Fred L wrote: > > SEAL provides a new signalling mechanism called "SCMP" > > which is intended to traverse firewalls that might block > > ICMP messages. SCMP messages include a message signature > > that the source node can use to determine whether the > > packet-in-error corresponds to a packet the node actually > > sent. Under what reasonable circumstances could even a > > paranoid firewall block that? >=20 > "SEAL? We're not using it, so let's block it" SEAL can be (con)seal(ed) within any outer layers of encapsulation. For example, it can appear as an IP protocol number, a TCP/UDP port number, or even buried within additional layers of encapsulation involving, e.g., TLS/SSL, IPsec, etc. I think the LISP team is counting on being able to ship things around within a simple outer IP/UDP encapsulation, so SEAL should be equally deployable (or not) within such an encapsulation. > [Without knowing about SEAL or its packets' syntax] >=20 > Bottom-line is that unless you're protocol cannot easily be > distinguished from some widely-deployed/widely-used protocol, it's > probably going to be blocked. That's why e.g. firewall-friendly > protocols tend to run over HTTP. SEAL can do that, too... > P.S.: I'm just the messenger... Right - no one is blaming you. Fred fred.l.templin@boeing.com =20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > = From fgont@si6networks.com Thu Jan 5 17:33:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E53A11E808D for ; Thu, 5 Jan 2012 17:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Njesk4PfyjEU for ; Thu, 5 Jan 2012 17:33:35 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id B979811E807A for ; Thu, 5 Jan 2012 17:33:34 -0800 (PST) Received: from [190.48.248.59] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiyDm-0005dq-AE; Fri, 06 Jan 2012 02:03:50 +0100 Message-ID: <4F062A35.2010207@si6networks.com> Date: Thu, 05 Jan 2012 19:54:45 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <82sjjxqisl.fsf@mid.bfk.de> <4F036A8A.9000806@si6networks.com> <82obuiig25.fsf@mid.bfk.de> In-Reply-To: <82obuiig25.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:33:35 -0000 On 01/05/2012 07:45 AM, Florian Weimer wrote: > Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might > be others, of course). Not sending them breaks important transition > technology. Looks like FreeBSD should patch. :-) >>> Without the API change in draft-andrews-6man-force-fragmentation, it is >>> flat out impossible to server IPv6 traffic in a stateless fashion. The >>> stack is required to keep a per-destination cache which records the >>> necessity of a fragment extension header, even if the application never >>> sends any packets larger than 1280 bytes. >> >> The stack is required to have a Destination Cache, anyway. > > Could you elaborate on that? For some operators, the ability to serve > stateless protocols statelessly over IPv6 is quite important. I'm not > aware of any fundamental requirement for per-destination bookkeeping in > IPv6 nodes. The Destinations Cache is described in the IPv6 specs themselves (RFC4861?), and is not a requirement of PMTUD. Typically, if you maintain PMTUD information, you already have a PMTUD cache in place, and you'd sort of had to patch the kernel if you wanted to eliminate that. >>>> Sorry, I cannot see why some packets would require going through a >>>> translator, while others wouldn't. >>> >>> The joy of packet switching. 8-) >> >> If a packet is actually destined to the IPv4 world (and hence needs to >> go through a translator), it will need to cross one translator, or >> another... but *some* translator. > > Couldn't it be translated back to IPv6? Then there could be an > IPv6-only path between sender and recipient. Huh? If any packet of that communication instances crossed a translator is because it was an IPv6 packet destined to an IPv4 node (i.e., the packets is ultimately destined to an IPv4 address). That will remain true for the life of that communication instance. So if one packet needed a translator, so will the others. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Jan 5 17:33:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DE111E807A for ; Thu, 5 Jan 2012 17:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L0uFBf4EZus for ; Thu, 5 Jan 2012 17:33:35 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 429B311E8088 for ; Thu, 5 Jan 2012 17:33:35 -0800 (PST) Received: from [190.48.248.59] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiyDb-0005dl-79; Fri, 06 Jan 2012 02:03:39 +0100 Message-ID: <4F0627EE.8010804@si6networks.com> Date: Thu, 05 Jan 2012 19:45:02 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Bjoern A. Zeeb" Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <4F028C42.1020702@si6networks.com> <8513FEFE-20AE-473B-9035-2270C7BA1FA8@lists.zabbadoz.net> <4F03BC4F.3020801@si6networks.com> <82pqeyjxz1.fsf@mid.bfk.de> <1B4D5CF3-AA0F-4AC2-A545-59AD9985B4F8@lists.zabbadoz.net> In-Reply-To: <1B4D5CF3-AA0F-4AC2-A545-59AD9985B4F8@lists.zabbadoz.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:33:35 -0000 On 01/05/2012 08:25 AM, Bjoern A. Zeeb wrote: > > What he means is remove the fragment header in this case without any other > fragment code processing and continue handling the packet as if you'd have > received it without the ext hdr. > > That this is still an expensive operation for a silly packet does not seem to > trickle down so avoiding these cases whenever possible should be the rule. Huh? What's your threat model? If you're concerned about being subject of... what? CPU-consumption attacks? -- guess what: an attacker would send you non-atomic fragments, just that you not only have to remove fragment headers, but also need to glue all the fragments together. Do you really think of atomic fragments as an attack vector? -- Attackers are much more clever than that... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Thu Jan 5 17:33:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D741211E809A for ; Thu, 5 Jan 2012 17:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.386 X-Spam-Level: X-Spam-Status: No, score=-0.386 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJUDR0Xe5Mny for ; Thu, 5 Jan 2012 17:33:40 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7311E8098 for ; Thu, 5 Jan 2012 17:33:40 -0800 (PST) Received: from [190.48.248.59] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RiygV-0005oD-Qd; Fri, 06 Jan 2012 02:33:32 +0100 Message-ID: <4F064C53.4060909@si6networks.com> Date: Thu, 05 Jan 2012 22:20:19 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Fragmentation-related security issues References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:33:41 -0000 On 01/05/2012 10:08 PM, Templin, Fred L wrote: >> On 01/04/2012 11:55 PM, Brian E Carpenter wrote: >> The problem with RFC4821 (assumming the ICMP-free variant) is that it >> has a longer convergnece time that ICMP-enabled PMTU. > > RFC4821 works even if there are no ICMPs, but will > converge more quickly if there are ICMPs. That is why > RFC4821 should be a SHOULD for hosts, and generation > of ICMPs should be a MUST for routers. Agreed. >> That's why people think of RFC4821 as a mechanism for PMTUD blackhole >> detection rathern than as a repalcement for traditional PMTUD >> (i.e., you >> use the transport-layer probes when it looks like >> tradictional PMTUD is >> not working (possibly as a result of filtered ICMP error messages)). > > The two are complementary. It was originally meant to be a replacement for traditional PMTUD. Then it was relaxed and RFC4821 allowed for it to be used only in the presence of PMTUD blackholes. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From marka@isc.org Thu Jan 5 18:07:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2511E8088 for ; Thu, 5 Jan 2012 18:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZA2Jp8rEfHy for ; Thu, 5 Jan 2012 18:07:19 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 9274B11E807A for ; Thu, 5 Jan 2012 18:07:18 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E9E3C5F98BF; Fri, 6 Jan 2012 02:06:58 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:19ba:ae94:8c13:6cc4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id D5288216C6E; Fri, 6 Jan 2012 02:06:56 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 2A0521AD6A63; Fri, 6 Jan 2012 13:06:54 +1100 (EST) To: Fernando Gont From: Mark Andrews References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <82ehvfnakx.fsf@mid.bfk.de> <4F048DD2.9050107@si6networks.com> <82lipmjxlg.fsf@mid.bfk.de> <4F060631.1070903@gont.com.ar> Subject: Re: Fragmentation-related security issues In-reply-to: Your message of "Thu, 05 Jan 2012 17:21:05 -0300." <4F060631.1070903@gont.com.ar> Date: Fri, 06 Jan 2012 13:06:54 +1100 Message-Id: <20120106020654.2A0521AD6A63@drugs.dv.isc.org> Cc: "Bjoern A. Zeeb" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 02:07:20 -0000 In message <4F060631.1070903@gont.com.ar>, Fernando Gont writes: > Florian, > > On 01/05/2012 06:40 AM, Florian Weimer wrote: > >>> Do we really know that adding a fragment header to all outgoing packets > >>> does not cause them to be rejected? > >> > >> Are you arguing that IPv6 fragmentation does no work at all, or what? > > > > I fear that it might work as well as in IPv4, that is, you can only get > > there with some effort, and for some nodes, it will never work. > > But that's an entirely different question. If you're thinking about e.g. > banning all fragmentation from IPv6, that's certainly completely > unrelated to the two I-D's that I've published on the subject... > > > > >>> Could this be deployed at large DNS servers in a risk-free fashion, > >>> for instance? > >> > >> What's the specific question you're asking, and what is your concern, > >> specifically? > > > > If DNS servers started sending either atomic fragments or fragmented > > responses today (i.e., all generated packets carry an IPv6 extension > > header), would these servers become unreachable for some clients? > > (I think we have to assume the answer is "yes".) > > Because some clients ignore atomic fragments, because fragments would be > dropped in the path to the client, or what? > > Note: I'm interested on the topic, but this one has to do more with Mark > Andrews' proposal than with mine. -- Mine is about how to improve the > state of affairs of IPv6 fragmentation. Mark's is about increasing its use. I'm more about making DNS work reliably. We have forced fragmentation of DNS/UDP/IPv6 datagrams, using IPV6_USE_MIN_MTU, since Jun 2000. Some other vendors havn't and that does result in operational problems as PMTUD is not reliable. Which can be seen when you repeatedly send the same DNS query to the same server but only get the last fragment when there is a tunnel in the reply path. Additionally, even if the PTB message gets through it is usually server to client traffic that gets dropped and servers don't keep a history of the responses they have sent over UDP so it requires a client timeout and requery to get the response resent. If you have a several of servers for a zone it can be several seconds before client retries the query to the first server, even with sub second timeouts, as the client assumes the server is *dead* and moves on to the next server. IPV6_USE_MIN_MTU works for clients that have a MTU path 1280 or greater. IPV6_USE_MIN_MTU does NOT work for clients that have a MTU path < 1280, which is a gap in spec. draft-andrews-6man-force-fragmentation is about filling in that gap. IPV6_USE_MIN_MTU was developed to deal with the issue of PMTUD being bad for DNS. draft-ietf-ipngwg-bsd-frag was the early work that eventually became IPV6_USE_MIN_MTU. > > IPv4 is different in this regard because clients can opt out from > > fragmented responses by requesting 512 byte responses (even if it's > > technically a DNS protocol violation). This is just not possible with > > IPv6---unless the server keeps per-client state, which is a non-starter > > for large DNS server deployments. > > Strictly speaking, that's not correct. Requesting 512-byte responses > does not necessarily avoid fragmentation. The IPv4 MTU is 68 bytes, not > 576. For instance, OpenBSD's imposes a lower limit of 296 (rather than > 576 or the like) because such low-MTU technologies exist. > > Thanks, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jmh@joelhalpern.com Thu Jan 5 18:08:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA611E8093 for ; Thu, 5 Jan 2012 18:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlBwn5hwMYYn for ; Thu, 5 Jan 2012 18:08:09 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1D59211E807A for ; Thu, 5 Jan 2012 18:08:09 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id EE41ECD177 for ; Thu, 5 Jan 2012 18:08:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 006F5C19FD; Thu, 5 Jan 2012 18:08:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-89.clppva.btas.verizon.net [71.161.50.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id EB316C19FC; Thu, 5 Jan 2012 18:08:06 -0800 (PST) Message-ID: <4F065789.9060102@joelhalpern.com> Date: Thu, 05 Jan 2012 21:08:09 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F0613FA.2060503@si6networks.com> In-Reply-To: <4F0613FA.2060503@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 02:08:09 -0000 Are we really prepared to say that there can be no new protocosl at the Internet or Transport layer, ever again. Not even new extensions? I do not think most folks ahve that view. But taht is the corrolary of the assumption that a) things need to work through firewalls b) that firewalls will and should block everything that they do not understand. There are contexts where such behavior is appropriate, and possibly even necessary. But if we take that as our design assumption, then we might as well stop lots of work we are doing. Yours, Joel On 1/5/2012 4:19 PM, Fernando Gont wrote: > On 01/05/2012 02:33 PM, Templin, Fred L wrote: >> SEAL provides a new signalling mechanism called "SCMP" >> which is intended to traverse firewalls that might block >> ICMP messages. SCMP messages include a message signature >> that the source node can use to determine whether the >> packet-in-error corresponds to a packet the node actually >> sent. Under what reasonable circumstances could even a >> paranoid firewall block that? > > "SEAL? We're not using it, so let's block it" > > [Without knowing about SEAL or its packets' syntax] > > Bottom-line is that unless you're protocol cannot easily be > distinguished from some widely-deployed/widely-used protocol, it's > probably going to be blocked. That's why e.g. firewall-friendly > protocols tend to run over HTTP. > > P.S.: I'm just the messenger... > > Thanks, From he@uninett.no Fri Jan 6 00:27:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3A121F889A for ; Fri, 6 Jan 2012 00:27:40 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BglNuvEB85cW for ; Fri, 6 Jan 2012 00:27:39 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDE021F848F for ; Fri, 6 Jan 2012 00:27:39 -0800 (PST) Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 7B3ED3D0B4; Fri, 6 Jan 2012 09:27:36 +0100 (CET) Date: Fri, 06 Jan 2012 09:27:36 +0100 (CET) Message-Id: <20120106.092736.505586056.he@uninett.no> To: Fred.L.Templin@boeing.com Subject: Re: Fragmentation-related security issues From: Havard Eidnes In-Reply-To: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipv6@ietf.org, brian.e.carpenter@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:27:40 -0000 >> The problem with RFC4821 (assumming the ICMP-free variant) is >> that it has a longer convergnece time that ICMP-enabled PMTU. > > RFC4821 works even if there are no ICMPs, but will > converge more quickly if there are ICMPs. That is why > RFC4821 should be a SHOULD for hosts, and generation > of ICMPs should be a MUST for routers. Does not this also imply that ICMP-generating routers MUST use a globally unique IPv6 address as the source of the ICMP? Regards, - H=E5vard From evyncke@cisco.com Fri Jan 6 00:51:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7A21F890F for ; Fri, 6 Jan 2012 00:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hijnTlD30ibP for ; Fri, 6 Jan 2012 00:51:57 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 206D021F890E for ; Fri, 6 Jan 2012 00:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=1553; q=dns/txt; s=iport; t=1325839917; x=1327049517; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=2TzL87XMZX9pEhIIVVoUbKhiyZkoe5EUjA9ls0uQCd0=; b=W+xlCS8mTxSnIRfol5pKkrqNURpL26zL6yTYO1jnPY7o7ANiAUs/LkNv pHJH3KX6lMuldudc4Ggpy9AiR8KKg6e5i3OCCA0raFzOlLr6IURsAVP2d UObYU7rzPpT103Lg9D+St9HWrGv5iE6MO2tKaQHeKbUOUt7aWhyC0l7qz o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKC1Bk+Q/khL/2dsb2JhbABDrQiBBYFyAQEBBAEBAQ8BHT4LDAQCAQgOAwQBAQsGFwEGASAGHwkIAQEEARIIGodgl20Bnh0Eiy5jBIgGl3GHRg X-IronPort-AV: E=Sophos;i="4.71,467,1320624000"; d="scan'208";a="62897580" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 Jan 2012 08:51:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q068ptUq007258; Fri, 6 Jan 2012 08:51:55 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 09:51:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Fragmentation-related security issues Date: Fri, 6 Jan 2012 09:51:53 +0100 Message-ID: <317616CE96204D49B5A1811098BA8950063A6ABB@XMB-AMS-110.cisco.com> In-Reply-To: <20120106.092736.505586056.he@uninett.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fragmentation-related security issues Thread-Index: AczMTRg7B13SoDkZQUmjGVTdwp9NTAAAsFpg References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> From: "Eric Vyncke (evyncke)" To: "Havard Eidnes" , X-OriginalArrivalTime: 06 Jan 2012 08:51:55.0962 (UTC) FILETIME=[717191A0:01CCCC50] Cc: ipv6@ietf.org, brian.e.carpenter@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 08:51:58 -0000 Hmmm while I understand the reasoning, I do not think that forcing core = routers to generate ICMP PTB messages is a good idea as this is done by = the route processor and not in silicon. This would be a nice DoS ;-) Their ICMP generation is usually rate limited (actually there is a HW = rate limiter on too-big packets). OTOH, core should never have a 'small MTU' link, so, this should be only = a problem in theory. -=E9ric > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of > Havard Eidnes > Sent: vendredi 6 janvier 2012 09:28 > To: Fred.L.Templin@boeing.com > Cc: ipv6@ietf.org; brian.e.carpenter@gmail.com > Subject: Re: Fragmentation-related security issues >=20 > >> The problem with RFC4821 (assumming the ICMP-free variant) is > >> that it has a longer convergnece time that ICMP-enabled PMTU. > > > > RFC4821 works even if there are no ICMPs, but will > > converge more quickly if there are ICMPs. That is why > > RFC4821 should be a SHOULD for hosts, and generation > > of ICMPs should be a MUST for routers. >=20 > Does not this also imply that ICMP-generating routers MUST use a > globally unique IPv6 address as the source of the ICMP? >=20 > Regards, >=20 > - H=E5vard > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From dougb@dougbarton.us Fri Jan 6 01:09:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9A821F88C8 for ; Fri, 6 Jan 2012 01:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWB2xjTbaP+O for ; Fri, 6 Jan 2012 01:09:00 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC2421F88B9 for ; Fri, 6 Jan 2012 01:08:59 -0800 (PST) Received: (qmail 14781 invoked by uid 399); 6 Jan 2012 09:08:57 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 6 Jan 2012 09:08:57 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F06BA27.3030005@dougbarton.us> Date: Fri, 06 Jan 2012 01:08:55 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <82sjjxqisl.fsf@mid.bfk.de> <4F036A8A.9000806@si6networks.com> <82obuiig25.fsf@mid.bfk.de> <4F062A35.2010207@si6networks.com> In-Reply-To: <4F062A35.2010207@si6networks.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:09:01 -0000 On 01/05/2012 14:54, Fernando Gont wrote: > On 01/05/2012 07:45 AM, Florian Weimer wrote: >> > Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might >> > be others, of course). Not sending them breaks important transition >> > technology. > > Looks like FreeBSD should patch. :-) FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released almost a year ago. It's scheduled to EOL in a little more than a year. It would be much more interesting to know if the bug is still present in the stable/8 branch (which will see at least one more release) or more importantly, in the about-to-be-released 9.0. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From marka@isc.org Fri Jan 6 01:27:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60C21F88CB for ; Fri, 6 Jan 2012 01:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2JKs7Z8Agt2 for ; Fri, 6 Jan 2012 01:27:05 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 06E1321F88EA for ; Fri, 6 Jan 2012 01:26:35 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id E17D05F9865; Fri, 6 Jan 2012 09:26:07 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:49ec:cf59:8e4d:908]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 182FC216C6D; Fri, 6 Jan 2012 09:26:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 823191AD8FC9; Fri, 6 Jan 2012 20:25:57 +1100 (EST) To: Doug Barton From: Mark Andrews References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <82sjjxqisl.fsf@mid.bfk.de> <4F036A8A.9000806@si6networks.com> <82obuiig25.fsf@mid.bfk.de> <4F062A35.2010207@si6networks.com> <4F06BA27.3030005@dougbarton.us> Subject: Re: Fragmentation-related security issues In-reply-to: Your message of "Fri, 06 Jan 2012 01:08:55 -0800." <4F06BA27.3030005@dougbarton.us> Date: Fri, 06 Jan 2012 20:25:57 +1100 Message-Id: <20120106092557.823191AD8FC9@drugs.dv.isc.org> Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:27:05 -0000 In message <4F06BA27.3030005@dougbarton.us>, Doug Barton writes: > On 01/05/2012 14:54, Fernando Gont wrote: > > On 01/05/2012 07:45 AM, Florian Weimer wrote: > >> > Steinar wrote that atomic fragments break FreeBSD 7.4 (and there might > >> > be others, of course). Not sending them breaks important transition > >> > technology. > > > > Looks like FreeBSD should patch. :-) > > FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released > almost a year ago. It's scheduled to EOL in a little more than a year. > > It would be much more interesting to know if the bug is still present in > the stable/8 branch (which will see at least one more release) or more The bug is still in 8 stable: http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log > importantly, in the about-to-be-released 9.0. It's fixed in 9 stable. > Doug > > -- > > You can observe a lot just by watching. -- Yogi Berra > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From sthaug@nethelp.no Fri Jan 6 01:54:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97B21F88CB for ; Fri, 6 Jan 2012 01:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrIrG+mOPkrw for ; Fri, 6 Jan 2012 01:54:59 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 9C17A21F88C8 for ; Fri, 6 Jan 2012 01:54:58 -0800 (PST) Received: (qmail 95579 invoked from network); 6 Jan 2012 09:54:56 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 6 Jan 2012 09:54:56 -0000 Date: Fri, 06 Jan 2012 10:54:56 +0100 (CET) Message-Id: <20120106.105456.74658018.sthaug@nethelp.no> To: marka@isc.org Subject: Re: Fragmentation-related security issues From: sthaug@nethelp.no In-Reply-To: <20120106092557.823191AD8FC9@drugs.dv.isc.org> References: <4F062A35.2010207@si6networks.com> <4F06BA27.3030005@dougbarton.us> <20120106092557.823191AD8FC9@drugs.dv.isc.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 09:54:59 -0000 > > > Looks like FreeBSD should patch. :-) > > > > FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released > > almost a year ago. It's scheduled to EOL in a little more than a year. > > > > It would be much more interesting to know if the bug is still present in > > the stable/8 branch (which will see at least one more release) or more > > The bug is still in 8 stable: > http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log > > > importantly, in the about-to-be-released 9.0. > > It's fixed in 9 stable. Agreed. I said it was fixed in 8.2-STABLE, I was wrong. The FreeBSD bug id is kern/145733, see r1.63 in http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ipfw/ip_fw2.c I have patched my 8.2-STABLE with this patch, and it works well. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fernando.gont.netbook.win@gmail.com Fri Jan 6 02:12:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9608221F88C1 for ; Fri, 6 Jan 2012 02:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb2t4XnT8Ift for ; Fri, 6 Jan 2012 02:12:31 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6D21F88B6 for ; Fri, 6 Jan 2012 02:12:31 -0800 (PST) Received: by ggnk5 with SMTP id k5so706804ggn.31 for ; Fri, 06 Jan 2012 02:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Lt4R+0Tet/BLmX/mpv4J/jt2/OYiBBe+TnzNi55su/w=; b=aa8RvFY61O7xYMOipH4FLbGQa+WZ+XdStAMXfPyGWv9ygAmQgGk9I5kybVOcX57LPC 7q9bonsXX7jH+rtxXPEA5juNM3kRxHBP/M+LyUchu0gNSixU9s7FHPjcPEWACawQ4Kon uSqM49LxhTPIa1Br8lljbP4CLTlhh3SXl+Aa0= Received: by 10.101.205.26 with SMTP id h26mr2218526anq.72.1325844750671; Fri, 06 Jan 2012 02:12:30 -0800 (PST) Received: from [192.168.1.106] ([186.137.77.114]) by mx.google.com with ESMTPS id j11sm94549340anl.8.2012.01.06.02.12.28 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 02:12:30 -0800 (PST) Sender: Fernando Gont Message-ID: <4F066B23.5090602@gont.com.ar> Date: Fri, 06 Jan 2012 00:31:47 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: To firewall or not to firewall (was: Re: Fragmentation-related security issues) References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F0613FA.2060503@si6networks.com> <4F065789.9060102@joelhalpern.com> In-Reply-To: <4F065789.9060102@joelhalpern.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:12:31 -0000 On 01/05/2012 11:08 PM, Joel M. Halpern wrote: > Are we really prepared to say that there can be no new protocosl at the > Internet or Transport layer, ever again. Not even new extensions? I'm personally ready to admit that new transport protocols and new IPv4 options are hard to deploy. > I do not think most folks ahve that view. > But taht is the corrolary of the assumption that > a) things need to work through firewalls I don't have such assumption. Actually, I'm rather in the camp of what somebody wrote years ago "firewall-friendly protocols are really 'firewall-unfriendly', because they are designed to circumvent the policies specified by the firewall administrators". So I don't think that one should necessarily design protocols to work through firewalls. BUt at the same time one shouldn't be surprised if they don't. > b) that firewalls will and should block everything that they do not > understand. Well, firewalls generally enforce policies, and they generally try to allow the "good" stuff in, while keeping the "bad" stuff out, with the assumption that "good" is only that stuff that "I know and I need". When one wears the protocol-development hat, that's frustrating and ugly. When one wears the "security" hat, that's the obvious way to avoid trouble for stuff that you don't really need). As usual, it's also clear that taking things to the extreme is usually not a good idea. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Fri Jan 6 02:12:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819B321F88A5 for ; Fri, 6 Jan 2012 02:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.274 X-Spam-Level: X-Spam-Status: No, score=-0.274 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWj95SmtPoim for ; Fri, 6 Jan 2012 02:12:52 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6021F88B6 for ; Fri, 6 Jan 2012 02:12:52 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rj6ma-0001DD-ML; Fri, 06 Jan 2012 11:12:21 +0100 Message-ID: <4F06671B.9090501@si6networks.com> Date: Fri, 06 Jan 2012 00:14:35 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Mark Andrews Subject: Re: Fragmentation-related security issues References: <82fwgfk1ev.fsf@mid.bfk.de> <20111220.124458.41706285.sthaug@nethelp.no> <20120102.231616.74700645.sthaug@nethelp.no> <4F028C9B.4010704@si6networks.com> <82ehvfnakx.fsf@mid.bfk.de> <4F048DD2.9050107@si6networks.com> <82lipmjxlg.fsf@mid.bfk.de> <4F060631.1070903@gont.com.ar> <20120106020654.2A0521AD6A63@drugs.dv.isc.org> In-Reply-To: <20120106020654.2A0521AD6A63@drugs.dv.isc.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:12:53 -0000 On 01/05/2012 11:06 PM, Mark Andrews wrote: >> Because some clients ignore atomic fragments, because fragments would be >> dropped in the path to the client, or what? >> >> Note: I'm interested on the topic, but this one has to do more with Mark >> Andrews' proposal than with mine. -- Mine is about how to improve the >> state of affairs of IPv6 fragmentation. Mark's is about increasing its use. > > I'm more about making DNS work reliably. Yes, sorry. The point I tried to make was that none of my I-Ds on fragmentation argued in favour of an increased use of fragmentation. That said, at least to the extent that I have studied your proposal, I agree with it (support it). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Fri Jan 6 02:13:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE1521F8949 for ; Fri, 6 Jan 2012 02:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlzW+loUojE1 for ; Fri, 6 Jan 2012 02:12:59 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 0859F21F8946 for ; Fri, 6 Jan 2012 02:12:57 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rj6n9-0001Df-AE; Fri, 06 Jan 2012 11:12:55 +0100 Message-ID: <4F069953.1050203@si6networks.com> Date: Fri, 06 Jan 2012 03:48:51 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= Subject: Re: Atomic fragments: converging on something? References: <4F038BD2.6080805@si6networks.com> <4F04AA46.6090806@si6networks.com> <0359C3D2-3011-4676-A76A-B3244E151756@laposte.net> In-Reply-To: <0359C3D2-3011-4676-A76A-B3244E151756@laposte.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Timothy Hartrick , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:13:00 -0000 Hi, Rémi, On 01/05/2012 02:02 PM, Rémi Després wrote: > Hi Fernando, > > Full agreement on the substance of your draft, and support for an RFC based on it. > > However, I believe it should rather be a BCP than a Standard-track RFC. > (I don't see any need to standardize anything beyond what already exists.) How is this different from, e.g. standardizing that hosts should discard overlapping fragments on Std Track? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From jared@puck.nether.net Fri Jan 6 09:03:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBEF21F87B9 for ; Fri, 6 Jan 2012 09:03:23 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPjyV1VD+cAu for ; Fri, 6 Jan 2012 09:03:23 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6483E21F8989 for ; Fri, 6 Jan 2012 09:03:23 -0800 (PST) Received: from [10.31.201.15] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q06H2Zbx005558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jan 2012 12:02:36 -0500 Subject: Re: To firewall or not to firewall (was: Re: Fragmentation-related security issues) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <4F066B23.5090602@gont.com.ar> Date: Fri, 6 Jan 2012 12:03:17 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F0613FA.2060503@si6networks.com> <4F065789.9060102@joelhalpern.com> <4F066B23.5090602@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Fri, 06 Jan 2012 12:02:36 -0500 (EST) Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:03:24 -0000 On Jan 5, 2012, at 10:31 PM, Fernando Gont wrote: > On 01/05/2012 11:08 PM, Joel M. Halpern wrote: >> Are we really prepared to say that there can be no new protocosl at the >> Internet or Transport layer, ever again. Not even new extensions? > > I'm personally ready to admit that new transport protocols and new IPv4 > options are hard to deploy. > > >> I do not think most folks ahve that view. >> But taht is the corrolary of the assumption that >> a) things need to work through firewalls > > I don't have such assumption. Actually, I'm rather in the camp of what > somebody wrote years ago "firewall-friendly protocols are really > 'firewall-unfriendly', because they are designed to circumvent the > policies specified by the firewall administrators". > > So I don't think that one should necessarily design protocols to work > through firewalls. BUt at the same time one shouldn't be surprised if > they don't. > > >> b) that firewalls will and should block everything that they do not >> understand. > > Well, firewalls generally enforce policies, and they generally try to > allow the "good" stuff in, while keeping the "bad" stuff out, with the > assumption that "good" is only that stuff that "I know and I need". > > When one wears the protocol-development hat, that's frustrating and > ugly. When one wears the "security" hat, that's the obvious way to avoid > trouble for stuff that you don't really need). > > As usual, it's also clear that taking things to the extreme is usually > not a good idea. I have to say, I'm certainly not as defeatist as Joel sounds, but I do hear his concern. I do firmly believe we can't solve everyones broken network issues or keep them from doing something wrong. - Jared From Fred.L.Templin@boeing.com Fri Jan 6 09:08:45 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187A521F8820 for ; Fri, 6 Jan 2012 09:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqVlqV0Zu4zq for ; Fri, 6 Jan 2012 09:08:44 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE77221F881F for ; Fri, 6 Jan 2012 09:08:12 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q06H8Xqe020801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2012 11:08:35 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q06H89i4025924; Fri, 6 Jan 2012 11:08:09 -0600 (CST) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q06H85gY025810 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 6 Jan 2012 11:08:06 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Fri, 6 Jan 2012 09:07:55 -0800 From: "Templin, Fred L" To: Havard Eidnes Date: Fri, 6 Jan 2012 09:07:54 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczMTRF3ldOSUPxbR9GiZDk9XkFwywASGkpQ Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> In-Reply-To: <20120106.092736.505586056.he@uninett.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , "brian.e.carpenter@gmail.com" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:08:45 -0000 =20 > -----Original Message----- > From: Havard Eidnes [mailto:he@uninett.no]=20 > Sent: Friday, January 06, 2012 12:28 AM > To: Templin, Fred L > Cc: fgont@si6networks.com; brian.e.carpenter@gmail.com; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > >> The problem with RFC4821 (assumming the ICMP-free variant) is > >> that it has a longer convergnece time that ICMP-enabled PMTU. > > > > RFC4821 works even if there are no ICMPs, but will > > converge more quickly if there are ICMPs. That is why > > RFC4821 should be a SHOULD for hosts, and generation > > of ICMPs should be a MUST for routers. >=20 > Does not this also imply that ICMP-generating routers MUST use a > globally unique IPv6 address as the source of the ICMP? AFAICT, the normative reference is RFC4443, as cited in RFC6434. Thanks - Fred fred.l.templin@boeing.com > Regards, >=20 > - H=E5vard > = From Fred.L.Templin@boeing.com Fri Jan 6 09:28:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1082B21F89A3 for ; Fri, 6 Jan 2012 09:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJF9SlUtUyPs for ; Fri, 6 Jan 2012 09:28:09 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6F26521F8684 for ; Fri, 6 Jan 2012 09:28:09 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q06HRuas018480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2012 09:28:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q06HRufw021131; Fri, 6 Jan 2012 09:27:56 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q06HRnR6020854 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 6 Jan 2012 09:27:50 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 6 Jan 2012 09:27:49 -0800 From: "Templin, Fred L" To: Fernando Gont , "Joel M. Halpern" Date: Fri, 6 Jan 2012 09:27:48 -0800 Subject: RE: To firewall or not to firewall (was: Re: Fragmentation-related security issues) Thread-Topic: To firewall or not to firewall (was: Re: Fragmentation-related security issues) Thread-Index: AczMW7kKwo/XPDa3T5iKWkwi9M1qSwAO+9Xg Message-ID: References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F0613FA.2060503@si6networks.com> <4F065789.9060102@joelhalpern.com> <4F066B23.5090602@gont.com.ar> In-Reply-To: <4F066B23.5090602@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 17:28:10 -0000 Hi Fernando,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Thursday, January 05, 2012 7:32 PM > To: Joel M. Halpern > Cc: ipv6@ietf.org; Brian E Carpenter > Subject: To firewall or not to firewall (was: Re:=20 > Fragmentation-related security issues) >=20 > On 01/05/2012 11:08 PM, Joel M. Halpern wrote: > > Are we really prepared to say that there can be no new=20 > protocosl at the > > Internet or Transport layer, ever again. Not even new extensions? >=20 > I'm personally ready to admit that new transport protocols=20 > and new IPv4 > options are hard to deploy. SEAL at least does not require a new transport protocol nor new IP options in all of its manifestations, i.e., it can be embedded within TCP/UDP just fine. =20 > > I do not think most folks ahve that view. > > But taht is the corrolary of the assumption that > > a) things need to work through firewalls >=20 > I don't have such assumption. Actually, I'm rather in the camp of what > somebody wrote years ago "firewall-friendly protocols are really > 'firewall-unfriendly', because they are designed to circumvent the > policies specified by the firewall administrators". >=20 > So I don't think that one should necessarily design protocols to work > through firewalls. BUt at the same time one shouldn't be surprised if > they don't. Some of these encapsulation approaches get around this by maintaining multiple candidate paths, and testing to find one or more of the candidates that are working. A candidate path that would traverse a blocking firewall would just be seen as a non-working path. Thanks - Fred fred.l.templin@boeing.com > > b) that firewalls will and should block everything that they do not > > understand. >=20 > Well, firewalls generally enforce policies, and they generally try to > allow the "good" stuff in, while keeping the "bad" stuff out, with the > assumption that "good" is only that stuff that "I know and I need". >=20 > When one wears the protocol-development hat, that's frustrating and > ugly. When one wears the "security" hat, that's the obvious=20 > way to avoid > trouble for stuff that you don't really need). >=20 > As usual, it's also clear that taking things to the extreme is usually > not a good idea. >=20 > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From brian.e.carpenter@gmail.com Fri Jan 6 12:20:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C29E821F87ED for ; Fri, 6 Jan 2012 12:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcMDtNahjcSC for ; Fri, 6 Jan 2012 12:20:53 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E45321F87E3 for ; Fri, 6 Jan 2012 12:20:50 -0800 (PST) Received: by eekc14 with SMTP id c14so1318998eek.31 for ; Fri, 06 Jan 2012 12:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7KbptXl3XjDgoA8qeV7VgaJ+N0z67ePcCKhLRIFjPjI=; b=TaSTHJeLoD2xrkocoTVWAGyiIUCCUF5yd8Kew8fJeZY3w5GOo5MvruCXaNaNccQuvo 1vhtJP0fP70xcIk+u3kuKUo/v/NjbWUfJQOADVIPuUnEi25+3SF54VFk4LH3vLY1NYU8 inTiJksHuw2hW9270cRYGDdUh+aopkmOegDKA= Received: by 10.14.9.160 with SMTP id 32mr2772740eet.63.1325881249001; Fri, 06 Jan 2012 12:20:49 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id t59sm252140121eeh.10.2012.01.06.12.20.45 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 12:20:48 -0800 (PST) Message-ID: <4F075796.9000905@gmail.com> Date: Sat, 07 Jan 2012 09:20:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jared Mauch Subject: Re: To firewall or not to firewall References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F0613FA.2060503@si6networks.com> <4F065789.9060102@joelhalpern.com> <4F066B23.5090602@gont.com.ar> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:20:54 -0000 On 2012-01-07 06:03, Jared Mauch wrote: > On Jan 5, 2012, at 10:31 PM, Fernando Gont wrote: > >> On 01/05/2012 11:08 PM, Joel M. Halpern wrote: >>> Are we really prepared to say that there can be no new protocosl at the >>> Internet or Transport layer, ever again. Not even new extensions? >> I'm personally ready to admit that new transport protocols and new IPv4 >> options are hard to deploy. >> >> >>> I do not think most folks ahve that view. >>> But taht is the corrolary of the assumption that >>> a) things need to work through firewalls >> I don't have such assumption. Actually, I'm rather in the camp of what >> somebody wrote years ago "firewall-friendly protocols are really >> 'firewall-unfriendly', because they are designed to circumvent the >> policies specified by the firewall administrators". >> >> So I don't think that one should necessarily design protocols to work >> through firewalls. BUt at the same time one shouldn't be surprised if >> they don't. >> >> >>> b) that firewalls will and should block everything that they do not >>> understand. >> Well, firewalls generally enforce policies, and they generally try to >> allow the "good" stuff in, while keeping the "bad" stuff out, with the >> assumption that "good" is only that stuff that "I know and I need". >> >> When one wears the protocol-development hat, that's frustrating and >> ugly. When one wears the "security" hat, that's the obvious way to avoid >> trouble for stuff that you don't really need). >> >> As usual, it's also clear that taking things to the extreme is usually >> not a good idea. > > > I have to say, I'm certainly not as defeatist as Joel sounds, but I do > hear his concern. > > I do firmly believe we can't solve everyones broken network issues or > keep them from doing something wrong. Somehow, it doesn't seem as if RFC 2979 is having much impact these days. It's definitely off-topic for this WG, but maybe it's time that the IETF faced up to firewalls in the same way that BEHAVE has faced up to NATs. Brian From brian.e.carpenter@gmail.com Fri Jan 6 12:26:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5ED521F8809 for ; Fri, 6 Jan 2012 12:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.57 X-Spam-Level: X-Spam-Status: No, score=-103.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yDU1EDl6nEl for ; Fri, 6 Jan 2012 12:26:57 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE25021F8801 for ; Fri, 6 Jan 2012 12:26:56 -0800 (PST) Received: by eekc14 with SMTP id c14so1321757eek.31 for ; Fri, 06 Jan 2012 12:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CSv8DAhgNodArmHxjTqFAq9UE420JEOUSYqBFk/d3J8=; b=j0s1oRIG/9kj9+vLcoXJga0EScvnrGVTDnBFa3nIHlY8VhbFEXTU8V1EBBjmm6rWpB TYHsrorewRgCWhCtPs76xvPbmAlasgEzBG+kBQSFW9e5OtKlsNboEAjoHydID98RiRne GcKrlQmgaMg0yKjrSeg5bCPfU2kCZltVyl4fo= Received: by 10.213.13.10 with SMTP id z10mr1518439ebz.63.1325881616154; Fri, 06 Jan 2012 12:26:56 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id b49sm221130108eec.9.2012.01.06.12.26.52 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 12:26:55 -0800 (PST) Message-ID: <4F075905.1090109@gmail.com> Date: Sat, 07 Jan 2012 09:26:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Havard Eidnes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:26:57 -0000 On 2012-01-07 06:07, Templin, Fred L wrote: > > >> -----Original Message----- >> From: Havard Eidnes [mailto:he@uninett.no] >> Sent: Friday, January 06, 2012 12:28 AM >> To: Templin, Fred L >> Cc: fgont@si6networks.com; brian.e.carpenter@gmail.com; ipv6@ietf.org >> Subject: Re: Fragmentation-related security issues >> >>>> The problem with RFC4821 (assumming the ICMP-free variant) is >>>> that it has a longer convergnece time that ICMP-enabled PMTU. >>> RFC4821 works even if there are no ICMPs, but will >>> converge more quickly if there are ICMPs. That is why >>> RFC4821 should be a SHOULD for hosts, and generation >>> of ICMPs should be a MUST for routers. >> Does not this also imply that ICMP-generating routers MUST use a >> globally unique IPv6 address as the source of the ICMP? > > AFAICT, the normative reference is RFC4443, as cited > in RFC6434. As I think we noticed recently in some other thread, there is therefore an operational requirement that all routers must possess at least one GUA. As far as I know, some routers can work just fine for all other purposes with only link-local addresses. Brian From brian.e.carpenter@gmail.com Fri Jan 6 12:36:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9698B11E80B7 for ; Fri, 6 Jan 2012 12:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-M6vzc9yyBL for ; Fri, 6 Jan 2012 12:36:14 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9676011E80BA for ; Fri, 6 Jan 2012 12:36:13 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id c14so1325577eek.31 for ; Fri, 06 Jan 2012 12:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KNefuBK9jeDvvQCV5fJyKZ7ZVgu+TXzQVMPoNttoZsI=; b=xigso8YaDkumn6lgyPDOcbaL+tzIWEP2t7mskf+psiWY3oZKJ3jt4f056hbLew513h 4XOqHs+gGYUEvaPmU2rL1IyiZUXIp2vD5PCHGtw7zsYjn5aVtt3fzXiv2cuHXqdurgSG Q/ihF4cDLLY3QdV4vjoy+4hkGY5JBKDequpT0= Received: by 10.14.95.140 with SMTP id p12mr2749065eef.105.1325882173257; Fri, 06 Jan 2012 12:36:13 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y12sm251226758eeb.11.2012.01.06.12.36.10 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 12:36:12 -0800 (PST) Message-ID: <4F075B33.3090206@gmail.com> Date: Sat, 07 Jan 2012 09:36:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Non-traditional PMTUD [was Re: Fragmentation-related security issues] References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> In-Reply-To: <4F05253F.8060705@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:36:14 -0000 On 2012-01-05 17:21, Fernando Gont wrote: > On 01/04/2012 11:55 PM, Brian E Carpenter wrote: >> That's why RFC 4821 describes MTU probing hidden in the transport >> layer, where hopefully firewalls would let it be. You will >> probably look in vain for widely deployed versions of RFC 4821. > > The problem with RFC4821 (assumming the ICMP-free variant) is that it > has a longer convergnece time that ICMP-enabled PMTU. > > That's why people think of RFC4821 as a mechanism for PMTUD blackhole > detection rathern than as a repalcement for traditional PMTUD (i.e., you > use the transport-layer probes when it looks like tradictional PMTUD is > not working (possibly as a result of filtered ICMP error messages)). "when it looks like" is the statement of an AI problem. I think we were talking about the case where the happy-eyeballs heuristic fails inelegantly because SYN/ACK worked fine but PMTUD (or possibly MSS negotiation) failed. In that case, the happy-eyeballs state machine as described so far doesn't know that it needs to do anything more. So this pretty much needs to be done spontaneously by the transport layer, if SYN/ACK succeeds but no further traffic occurs. I have nothing to suggest for UDP. Brian From Fred.L.Templin@boeing.com Fri Jan 6 12:52:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F2A21F877C for ; Fri, 6 Jan 2012 12:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBjDMyLALtFk for ; Fri, 6 Jan 2012 12:52:40 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id EE0CB21F875B for ; Fri, 6 Jan 2012 12:52:35 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q06KqvmQ013016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2012 14:53:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q06KqXrn022769; Fri, 6 Jan 2012 14:52:34 -0600 (CST) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q06KqMAa022248 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 6 Jan 2012 14:52:23 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Fri, 6 Jan 2012 12:52:11 -0800 From: "Templin, Fred L" To: Brian E Carpenter Date: Fri, 6 Jan 2012 12:52:11 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczMsaTiYTTizSJzTsCUEHSATh45vQAAxvuQ Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> In-Reply-To: <4F075905.1090109@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipv6@ietf.org" , Havard Eidnes X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:52:41 -0000 Hi Brian,=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > Sent: Friday, January 06, 2012 12:27 PM > To: Templin, Fred L > Cc: Havard Eidnes; fgont@si6networks.com; ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > On 2012-01-07 06:07, Templin, Fred L wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Havard Eidnes [mailto:he@uninett.no]=20 > >> Sent: Friday, January 06, 2012 12:28 AM > >> To: Templin, Fred L > >> Cc: fgont@si6networks.com; brian.e.carpenter@gmail.com;=20 > ipv6@ietf.org > >> Subject: Re: Fragmentation-related security issues > >> > >>>> The problem with RFC4821 (assumming the ICMP-free variant) is > >>>> that it has a longer convergnece time that ICMP-enabled PMTU. > >>> RFC4821 works even if there are no ICMPs, but will > >>> converge more quickly if there are ICMPs. That is why > >>> RFC4821 should be a SHOULD for hosts, and generation > >>> of ICMPs should be a MUST for routers. > >> Does not this also imply that ICMP-generating routers MUST use a > >> globally unique IPv6 address as the source of the ICMP? > >=20 > > AFAICT, the normative reference is RFC4443, as cited > > in RFC6434. >=20 > As I think we noticed recently in some other thread, there is > therefore an operational requirement that all routers must > possess at least one GUA. As far as I know, some routers can work > just fine for all other purposes with only link-local addresses. So - can't the router just autoconfigure a ULA and use it as the SA for ICMPs? Thanks - Fred > Brian > = From brian@innovationslab.net Fri Jan 6 12:57:56 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC1121F87B0 for ; Fri, 6 Jan 2012 12:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzNgsFKfXP2a for ; Fri, 6 Jan 2012 12:57:56 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9121F8784 for ; Fri, 6 Jan 2012 12:57:56 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D4721880CF for ; Fri, 6 Jan 2012 12:57:55 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 7BE7A130002 for ; Fri, 6 Jan 2012 12:57:55 -0800 (PST) Message-ID: <4F076052.6080800@innovationslab.net> Date: Fri, 06 Jan 2012 15:57:54 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:57:56 -0000 Fred, On 1/6/12 3:52 PM, Templin, Fred L wrote: > Hi Brian, > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Friday, January 06, 2012 12:27 PM >> To: Templin, Fred L >> Cc: Havard Eidnes; fgont@si6networks.com; ipv6@ietf.org >> Subject: Re: Fragmentation-related security issues >> >> On 2012-01-07 06:07, Templin, Fred L wrote: >>> >>> >>>> -----Original Message----- >>>> From: Havard Eidnes [mailto:he@uninett.no] >>>> Sent: Friday, January 06, 2012 12:28 AM >>>> To: Templin, Fred L >>>> Cc: fgont@si6networks.com; brian.e.carpenter@gmail.com; >> ipv6@ietf.org >>>> Subject: Re: Fragmentation-related security issues >>>> >>>>>> The problem with RFC4821 (assumming the ICMP-free variant) is >>>>>> that it has a longer convergnece time that ICMP-enabled PMTU. >>>>> RFC4821 works even if there are no ICMPs, but will >>>>> converge more quickly if there are ICMPs. That is why >>>>> RFC4821 should be a SHOULD for hosts, and generation >>>>> of ICMPs should be a MUST for routers. >>>> Does not this also imply that ICMP-generating routers MUST use a >>>> globally unique IPv6 address as the source of the ICMP? >>> >>> AFAICT, the normative reference is RFC4443, as cited >>> in RFC6434. >> >> As I think we noticed recently in some other thread, there is >> therefore an operational requirement that all routers must >> possess at least one GUA. As far as I know, some routers can work >> just fine for all other purposes with only link-local addresses. > > So - can't the router just autoconfigure a ULA and use > it as the SA for ICMPs? The ULA will have no meaning for ICMP messages that leave the administrative domain. Regards, Brian From brian.e.carpenter@gmail.com Fri Jan 6 13:06:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EF221F87F1 for ; Fri, 6 Jan 2012 13:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.272 X-Spam-Level: X-Spam-Status: No, score=-103.272 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j6hKQguyaH2 for ; Fri, 6 Jan 2012 13:06:48 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73D8A21F87EB for ; Fri, 6 Jan 2012 13:06:48 -0800 (PST) Received: by eekc14 with SMTP id c14so1339532eek.31 for ; Fri, 06 Jan 2012 13:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ASG+zlK5kX3n0ZDZeGYU/tkg9JvP+0KJ1z3jme+Ve+0=; b=BRgza1ahHWuf8TWsWrJ5GRXwtrJrW3jTcc7gzBcWjRQMtNnD29Snu5jyxmzOAY5rsc 6si7md6g1LI3xUNTnXiX6jJMPg5/ebyIdaF0kCrEyOA+/7f78ge5J7K35smEAPzwX7Xi BGosvXlZ3sBHKxyBmCZjCg0J4aduPhhjjj0GI= Received: by 10.213.26.213 with SMTP id f21mr1542400ebc.27.1325884006241; Fri, 06 Jan 2012 13:06:46 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u53sm204761291eeu.6.2012.01.06.13.06.43 (version=SSLv3 cipher=OTHER); Fri, 06 Jan 2012 13:06:45 -0800 (PST) Message-ID: <4F07625C.6090800@gmail.com> Date: Sat, 07 Jan 2012 10:06:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Haberman Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> In-Reply-To: <4F076052.6080800@innovationslab.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:06:49 -0000 On 2012-01-07 09:57, Brian Haberman wrote: > Fred, > > On 1/6/12 3:52 PM, Templin, Fred L wrote: >> Hi Brian, >> >>> -----Original Message----- >>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>> Sent: Friday, January 06, 2012 12:27 PM >>> To: Templin, Fred L >>> Cc: Havard Eidnes; fgont@si6networks.com; ipv6@ietf.org >>> Subject: Re: Fragmentation-related security issues >>> >>> On 2012-01-07 06:07, Templin, Fred L wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Havard Eidnes [mailto:he@uninett.no] >>>>> Sent: Friday, January 06, 2012 12:28 AM >>>>> To: Templin, Fred L >>>>> Cc: fgont@si6networks.com; brian.e.carpenter@gmail.com; >>> ipv6@ietf.org >>>>> Subject: Re: Fragmentation-related security issues >>>>> >>>>>>> The problem with RFC4821 (assumming the ICMP-free variant) is >>>>>>> that it has a longer convergnece time that ICMP-enabled PMTU. >>>>>> RFC4821 works even if there are no ICMPs, but will >>>>>> converge more quickly if there are ICMPs. That is why >>>>>> RFC4821 should be a SHOULD for hosts, and generation >>>>>> of ICMPs should be a MUST for routers. >>>>> Does not this also imply that ICMP-generating routers MUST use a >>>>> globally unique IPv6 address as the source of the ICMP? >>>> AFAICT, the normative reference is RFC4443, as cited >>>> in RFC6434. >>> As I think we noticed recently in some other thread, there is >>> therefore an operational requirement that all routers must >>> possess at least one GUA. As far as I know, some routers can work >>> just fine for all other purposes with only link-local addresses. >> So - can't the router just autoconfigure a ULA and use >> it as the SA for ICMPs? > > The ULA will have no meaning for ICMP messages that leave the > administrative domain. That doesn't matter, to avoid the issue covered in the long thread "Routers forwarding packet with link local source" on v6ops last month. Brian C From Fred.L.Templin@boeing.com Fri Jan 6 13:44:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066ED1F0C71 for ; Fri, 6 Jan 2012 13:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUWP-RbTr4BV for ; Fri, 6 Jan 2012 13:44:17 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id C90A11F0C6F for ; Fri, 6 Jan 2012 13:44:13 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q06Li7hC000857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2012 13:44:07 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q06Li7IG022655; Fri, 6 Jan 2012 13:44:07 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q06Li62X022643 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 6 Jan 2012 13:44:06 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Fri, 6 Jan 2012 13:44:06 -0800 From: "Templin, Fred L" To: Brian Haberman , "ipv6@ietf.org" Date: Fri, 6 Jan 2012 13:44:05 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczMteGJYcGsmQwSTt2O1mt4TQEQ7QABYHPQ Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> In-Reply-To: <4F076052.6080800@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:44:18 -0000 Hi Brian,=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Brian Haberman > Sent: Friday, January 06, 2012 12:58 PM > To: ipv6@ietf.org > Subject: Re: Fragmentation-related security issues >=20 > Fred, >=20 > On 1/6/12 3:52 PM, Templin, Fred L wrote: > > Hi Brian,=20 > >=20 > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 > >> Sent: Friday, January 06, 2012 12:27 PM > >> To: Templin, Fred L > >> Cc: Havard Eidnes; fgont@si6networks.com; ipv6@ietf.org > >> Subject: Re: Fragmentation-related security issues > >> > >> On 2012-01-07 06:07, Templin, Fred L wrote: > >>> =20 > >>> > >>>> -----Original Message----- > >>>> From: Havard Eidnes [mailto:he@uninett.no]=20 > >>>> Sent: Friday, January 06, 2012 12:28 AM > >>>> To: Templin, Fred L > >>>> Cc: fgont@si6networks.com; brian.e.carpenter@gmail.com;=20 > >> ipv6@ietf.org > >>>> Subject: Re: Fragmentation-related security issues > >>>> > >>>>>> The problem with RFC4821 (assumming the ICMP-free variant) is > >>>>>> that it has a longer convergnece time that ICMP-enabled PMTU. > >>>>> RFC4821 works even if there are no ICMPs, but will > >>>>> converge more quickly if there are ICMPs. That is why > >>>>> RFC4821 should be a SHOULD for hosts, and generation > >>>>> of ICMPs should be a MUST for routers. > >>>> Does not this also imply that ICMP-generating routers MUST use a > >>>> globally unique IPv6 address as the source of the ICMP? > >>> > >>> AFAICT, the normative reference is RFC4443, as cited > >>> in RFC6434. > >> > >> As I think we noticed recently in some other thread, there is > >> therefore an operational requirement that all routers must > >> possess at least one GUA. As far as I know, some routers can work > >> just fine for all other purposes with only link-local addresses. > >=20 > > So - can't the router just autoconfigure a ULA and use > > it as the SA for ICMPs? >=20 > The ULA will have no meaning for ICMP messages that leave the > administrative domain. I don't think it needs to have meaning - unless there were some application that wanted to try to geo-locate the router based on the IP address? The ULA would only be there to placate the routing system, which cannot forward packets with LL source addresses. In general, though, AFAICT the source address of an ICMP error message such as PTB coming from the network of little value to the node in deciding whether to accept it. Thanks - Fred > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From dougb@dougbarton.us Fri Jan 6 14:22:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8454121F87DF for ; Fri, 6 Jan 2012 14:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5qBw-UDFlVX for ; Fri, 6 Jan 2012 14:22:20 -0800 (PST) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9512621F87DB for ; Fri, 6 Jan 2012 14:22:20 -0800 (PST) Received: (qmail 22212 invoked by uid 399); 6 Jan 2012 22:22:14 -0000 Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 6 Jan 2012 22:22:14 -0000 X-Originating-IP: 12.207.105.210 X-Sender: dougb@dougbarton.us Message-ID: <4F077415.8070808@dougbarton.us> Date: Fri, 06 Jan 2012 14:22:13 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: sthaug@nethelp.no Subject: Re: Fragmentation-related security issues References: <4F062A35.2010207@si6networks.com> <4F06BA27.3030005@dougbarton.us> <20120106092557.823191AD8FC9@drugs.dv.isc.org> <20120106.105456.74658018.sthaug@nethelp.no> In-Reply-To: <20120106.105456.74658018.sthaug@nethelp.no> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bz@FreeBSD.org, ipv6@ietf.org, marka@isc.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 22:22:21 -0000 On 01/06/2012 01:54, sthaug@nethelp.no wrote: >>>> Looks like FreeBSD should patch. :-) >>> >>> FYI, FreeBSD 7.4 is the last release of the 7.x branch, and was released >>> almost a year ago. It's scheduled to EOL in a little more than a year. >>> >>> It would be much more interesting to know if the bug is still present in >>> the stable/8 branch (which will see at least one more release) or more >> >> The bug is still in 8 stable: >> http://svnweb.freebsd.org/base/stable/8/sys/netinet/ipfw/ip_fw2.c?view=log >> >>> importantly, in the about-to-be-released 9.0. >> >> It's fixed in 9 stable. > > Agreed. I said it was fixed in 8.2-STABLE, I was wrong. The FreeBSD > bug id is kern/145733, see r1.63 in > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ipfw/ip_fw2.c > > I have patched my 8.2-STABLE with this patch, and it works well. Well that's good news. :) Bjoern owns that PR, perhaps he can comment on his plans for merging the fix to stable/8. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From fweimer@bfk.de Mon Jan 9 00:33:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7021F847F for ; Mon, 9 Jan 2012 00:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7vF523urX6t for ; Mon, 9 Jan 2012 00:33:00 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id EA87E21F8686 for ; Mon, 9 Jan 2012 00:32:58 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RkAf0-0007P7-SG; Mon, 09 Jan 2012 08:32:54 +0000 Received: by bfk.de with local id 1RkAf0-0005mK-FL; Mon, 09 Jan 2012 08:32:54 +0000 From: Florian Weimer To: Brian E Carpenter Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> Date: Mon, 09 Jan 2012 08:32:54 +0000 In-Reply-To: <4F07625C.6090800@gmail.com> (Brian E. Carpenter's message of "Sat, 07 Jan 2012 10:06:36 +1300") Message-ID: <82zkdxb7ih.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 08:33:00 -0000 * Brian E. Carpenter: >> The ULA will have no meaning for ICMP messages that leave the >> administrative domain. > > That doesn't matter, How do you implement BCP38 filters if the address lacks clear ownership? --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From despres.remi@laposte.net Mon Jan 9 01:28:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D917C21F86A8 for ; Mon, 9 Jan 2012 01:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUSDvOLrlLn9 for ; Mon, 9 Jan 2012 01:28:00 -0800 (PST) Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by ietfa.amsl.com (Postfix) with ESMTP id 29C4E21F849A for ; Mon, 9 Jan 2012 01:27:59 -0800 (PST) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 6248F700039E; Mon, 9 Jan 2012 10:27:57 +0100 (CET) Received: from [192.168.0.21] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2402.sfr.fr (SMTP Server) with ESMTP id 23F4D7000182; Mon, 9 Jan 2012 10:27:53 +0100 (CET) X-SFR-UUID: 20120109092753147.23F4D7000182@msfrf2402.sfr.fr Subject: Re: Atomic fragments: converging on something? Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F069953.1050203@si6networks.com> Date: Mon, 9 Jan 2012 10:27:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <03465188-A4B8-43C5-8382-55E5D776B9C8@laposte.net> References: <4F038BD2.6080805@si6networks.com> <4F04AA46.6090806@si6networks.com> <0359C3D2-3011-4676-A76A-B3244E151756@laposte.net> <4F069953.1050203@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) X-sfr-mailing: LEGIT Cc: Timothy Hartrick , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:28:01 -0000 Le 2012-01-06 =E0 07:48, Fernando Gont a =E9crit : > Hi, R=E9mi, >=20 > On 01/05/2012 02:02 PM, R=E9mi Despr=E9s wrote: >> Hi Fernando, >>=20 >> Full agreement on the substance of your draft, and support for an RFC = based on it. >>=20 >> However, I believe it should rather be a BCP than a Standard-track = RFC. >> (I don't see any need to standardize anything beyond what already = exists.) >=20 > How is this different from, e.g. standardizing that hosts should = discard > overlapping fragments on Std Track? Discarding receiving fragments that overlap (RFC is IMHO something that = might ALSO have been treated as BCP: it doesn't change the protocol. = (Implementations that don't comply with the new provision still = interwork with those that do.)=20 An ambiguity however exists in RFC 2460 because it describes a specific = reassembly algorithm without saying it isn't part of the standard. This = algorithm, which could have been left to implementors to choose based on = how sources do fragmentation, doesn't include the consistency check that = fragments don't overlap. It it then worth specifying that the described = algorithm isn't as complete as it could be. I have to agree that the logic of what you propose, although less = important IMHO, is similar.=20 Therefore, and despite my comment, I don't really care whether it ends = up as a standard rather than a BCP if others so prefer. Regards, RD >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 Sec 4.5 The following conditions are not expected to occur, but are not considered errors if they do: The number and content of the headers preceding the Fragment header of different fragments of the same original packet may differ. Whatever headers are present, preceding the Fragment header in each fragment packet, are processed when the packets arrive, prior to queueing the fragments for reassembly. Only those headers in the Offset zero fragment packet are retained in the reassembled packet. The Next Header values in the Fragment headers of different fragments of the same original packet may differ. Only the value from the Offset zero fragment packet is used for reassembly.= From fgont@si6networks.com Mon Jan 9 01:59:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C348321F86D4 for ; Mon, 9 Jan 2012 01:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.646 X-Spam-Level: X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR96+uqeQnfc for ; Mon, 9 Jan 2012 01:59:01 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 31DFC21F86B5 for ; Mon, 9 Jan 2012 01:59:01 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RkBzq-0001lK-NL; Mon, 09 Jan 2012 10:58:31 +0100 Message-ID: <4F07C98C.7000107@si6networks.com> Date: Sat, 07 Jan 2012 01:26:52 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <4F075B33.3090206@gmail.com> In-Reply-To: <4F075B33.3090206@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 09:59:01 -0000 On 01/06/2012 05:36 PM, Brian E Carpenter wrote: >> That's why people think of RFC4821 as a mechanism for PMTUD blackhole >> detection rathern than as a repalcement for traditional PMTUD (i.e., you >> use the transport-layer probes when it looks like tradictional PMTUD is >> not working (possibly as a result of filtered ICMP error messages)). > > "when it looks like" is the statement of an AI problem. I think we > were talking about the case where the happy-eyeballs heuristic fails > inelegantly because SYN/ACK worked fine but PMTUD (or possibly MSS > negotiation) failed. Sorry, I meant "it looks like PMTUD messages are being dropped" -- and yes, "looks like", because you cannot tell for sure. > In that case, the happy-eyeballs state machine > as described so far doesn't know that it needs to do anything more. > So this pretty much needs to be done spontaneously by the transport > layer, if SYN/ACK succeeds but no further traffic occurs. Sorry, not sure what you're referring to. I just said that PLPMTU has a long convergence time, and hence it's usually seen as a "PMTU blackhole detection/recovery mechanism", rather than as a replacement of traditional PMTUD. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Jan 9 02:00:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2767A21F8693 for ; Mon, 9 Jan 2012 02:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5scroh1Bgyx for ; Mon, 9 Jan 2012 02:00:09 -0800 (PST) Received: from srv01.bbserve.nl (srv01.bbserve.nl [46.21.160.232]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9621F8684 for ; Mon, 9 Jan 2012 02:00:09 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.106]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RkC1O-0001mV-6p; Mon, 09 Jan 2012 11:00:06 +0100 Message-ID: <4F0AB553.2040400@si6networks.com> Date: Mon, 09 Jan 2012 06:37:23 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> In-Reply-To: <82zkdxb7ih.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org, Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 10:00:10 -0000 On 01/09/2012 05:32 AM, Florian Weimer wrote: >>> The ULA will have no meaning for ICMP messages that leave the >>> administrative domain. >> >> That doesn't matter, > > How do you implement BCP38 filters if the address lacks clear ownership? Same thing would happen as it currently happens with ICMP error messages sourced from private addresses: some get "mysteriously" dropped. -- i.e. using ULAs for the source address of ICMPv6 messages seems like a very bad idea. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From chengang@chinamobile.com Sun Jan 8 19:03:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA5221F8621 for ; Sun, 8 Jan 2012 19:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.123 X-Spam-Level: * X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CA3bbDbbQOt for ; Sun, 8 Jan 2012 19:03:52 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0E85521F861A for ; Sun, 8 Jan 2012 19:03:40 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id BA252E795; Mon, 9 Jan 2012 11:03:32 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id AE6B2E793; Mon, 9 Jan 2012 11:03:32 +0800 (CST) Received: from LENOVO1E4798BB ([10.2.43.121]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012010911033024-5724 ; Mon, 9 Jan 2012 11:03:30 +0800 From: "ChenGang" To: =?iso-8859-1?Q?'R=E9mi_Despr=E9s'?= , "'Dan Wing'" References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <4EF5647B.6070903@si6networks.com> <4EF630C6.6050405@gmail.com> <4EF7D880.3090102@gont.com.ar> <002f01ccc9a2$9fab9990$df02ccb0$@com> <4F023C6B.4040401@si6networks.com> <004501ccca4a$3cd1b9f0$b6752dd0$@com> <4F0363E3.2010902@gmail.com> <01f701ccca58$4b7bd040$e27370c0$@com> <4581455F-282E-42E6-B328-CEB06620C844@free.fr> <043801cccafb$f754beb0$e5fe3c10$@com> <061d01cccb54$185a8a60$490f9f20$@com> Subject: RE: Fragmentation-related security issues Date: Mon, 9 Jan 2012 11:03:28 +0800 Message-ID: <0D5A30173D904D72B03F3B6DAD484F83@LENOVO1E4798BB> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.6157 In-Reply-To: Thread-Index: AczLibcdfH1LM5sVR6uSCzvN8wFTYQC8L3bA X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-01-09 11:03:30, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-01-09 11:03:31, Serialize complete at 2012-01-09 11:03:31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18634.004 X-TM-AS-Result: No--30.087-7.0-31-10 X-imss-scan-details: No--30.087-7.0-31-10;No--30.087-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No X-Mailman-Approved-At: Mon, 09 Jan 2012 02:40:31 -0800 Cc: draft-chen-v6ops-nat64-cpe@tools.ietf.org, ipv6@ietf.org, 'Brian E Carpenter' X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 03:03:53 -0000 Hello Dan and Remi, Thanks for providing this information to us. I have a glance on the discussion. As an author of draft-chen-v6ops-nat64-cpe, I think it's valuable to = state that as one of NAT64 experiences. I will bring my comments to the list after my second reading. Many thanks Gang -----Original Message----- From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr]=20 Sent: Thursday, January 05, 2012 5:09 PM To: Dan Wing Cc: 'Brian E Carpenter'; ipv6@ietf.org; draft-chen-v6ops-nat64-cpe@tools.ietf.org Subject: Re: Fragmentation-related security issues Le 2012-01-05 =E0 03:45, Dan Wing a =E9crit : >> -----Original Message----- >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >> Sent: Wednesday, January 04, 2012 9:47 AM >> To: Dan Wing >> Cc: 'Brian E Carpenter'; ipv6@ietf.org >> Subject: Re: Fragmentation-related security issues >>=20 >> Le 2012-01-04 =E0 17:14, Dan Wing a =E9crit : >>=20 >>>> -----Original Message----- >>>> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >>>> Sent: Wednesday, January 04, 2012 1:44 AM >>>> To: Dan Wing >>>> Cc: 'Brian E Carpenter'; ipv6@ietf.org >>>> Subject: Re: Fragmentation-related security issues >>>>=20 >>>> Hi Dan, >>>>=20 >>>> As you rightly reminded, the current specification permits PTB<1280 >> for >>>> a DST reached via a IPv6/IPv4 translator (an IPv4 DST), and forbids >> it >>>> for an IPv6 DST. >>>>=20 >>>> Rather than changing this, what about clarifying that a host SHOULD >>>> treat a received PTB>1280 as: >>>> - valid if the IPv6 DST was IPv4-embedded (starting with a pref64 = of >>>> RFC6147) >>>=20 >>> That only helps in half of the RFC6144 scenarios, where the IPv6 >>> host is behind the translator (e.g., "Scenario 1: an IPv6 network to >> the >>> IPv4 Internet"). It would not help in the other half of the RFC6144 >>> scenarios where the IPv6 host is on the Internet (e.g., "Scenario 4: >>> an IPv4 network to the IPv6 Internet"). It is RFC6144's Scenario 4 >>> where stateless IPv6/IPv4 translators, where the IPv4 network has a >>> small MTU, that there is a reliance on the last paragraph of Section >>> 5 of RFC2460. >>=20 >> You are right, refusing PTB<12810 if IPv6 DST was not recognized as >> IPv4-embedded would break scenarios 3 and 4. >> Will these scenarios be as typical as those where an IPv6-only host >> reaches an IPv4-only server is unclear, and even IMHO doubtful. >> Yet, I agree they must be considered. >>=20 >> - One approach would be to REQUIRE that IPv4 networks having = IPv6-only >> access to the Internet have MTU >=3D 1240 (requiring this ONLY for = these >> networks shouldn't be a big deal). >=20 > Yep. >=20 > That seems a reasonable statement for an "operational consideration"=20 > document to make. It might be reasonable for a NAT64 "operational=20 > considerations" document in either BEHAVE or V6OPS. =20 > Draft-chen-v6ops-nat64-cpe could be that document; although, as I=20 > stated at the microphone in IETF82, draft-chen-v6ops-nat64-cpe needs=20 > to more clearly separate itself into the various scenarios for=20 > a NAT64 device (that is, if the IPv6 network is "the Internet"=20 > (not operated by any one entity) or if the IPv6 network is=20 > "a network" (operated by the same entity operating the NAT64). > That is the same difference between RFC6144's Scenario 1 and 4.) Agreed. >=20 > CC'ing authors of draft-chen-v6ops-nat64-cpe. Good idea. >> - Another, non exclusive, would be that IPv4-embedded addresses of = such >> networks would be REQUIRED to have a specific format. (A V octet a la >> 4rd-U, instead of the u octet of RFC6052, could for instance do the >> job). >=20 > RFC6052 didn't define the "u" octet; rather, RFC6052 is merely=20 > preserving the "u" bit's meaning as originally defined in RFC4291. Well, RFC6052 does include in sec. 2.3 '... insert the null octet = "u"...' and '... remove the "u" octet...'. I agree that, in view of the privacy option that pre-existed, this = didn't add a new value of this octet (the point you make if I get it right). Yet, RFC6052 did introduce an interpretation of the u bit that, from a puristic point of view, would conflict with that of RFC4291:=20 - RFC4291 says: "the "u" bit is set to one (1) to indicate universal = scope, and it is set to zero (0) to indicate local scope".=20 - In RFC6052, 64:ff9b::X.X.X.X means IPv4 address X.X.X.X whose scope is universal despite its u=3D0. In my understanding, another RFC that would introduce a V octet using = the u=3Dv=3D1 escape combination wouldn't conflict with RFC4291 more than = RFC4291 does, i.e. acceptably little. RD =20 =20 >=20 > -d >=20 >=20 >> RD >>=20 >>=20 >>=20 >>>=20 >>> -d >>>=20 >>>> - an ERROR otherwise. >>>>=20 >>>> This would at least dissuade from tolerating IPv6 paths with PMTU < >>>> 1280. >>>>=20 >>>> RD >>>>=20 >>>>=20 >>>>=20 >>>> Le 2012-01-03 =E0 21:43, Dan Wing a =E9crit : >>>>>> ... >>>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >>>>>> ... >>>>>> On 2012-01-04 08:02, Dan Wing wrote: >>>>>>> ... >>>>>>> So, I don't think we can just wish away packet-too-big < 1280. >>>>>>=20 >>>>>> Sadly, that seems to be true unless we make a much more radical >>>> change, >>>>>> because of translators. >>>>>=20 >>>>> Or, we declare a new restriction that translators are not expected >> to >>>>> work if the IPv4 network has an MTU less than 1260 = (1260=3D1280-20, >>>>> because IPv6 header is 20B bigger than IPv4 header). I don't know >> if >>>> there >>>>> is consensus for such a restriction. To date, both RFC2765 and >>>> RFC6145 >>>>> avoided such a restriction. However, if there are widespread IPv6 >>>>> host implementations or firewalls that erroneously filter or = ignore >>>>> ICMP PTB < 1280, it may force IPv6/IPv4 translator deployments to >>>>> accept that restriction, and modify their IPv4 networks to have >>>>> MTU>=3D1260. Such IPv4 network modifications would add to further >>>>> pain to IPv6 coexistence. MTU research by Ben Stasiewicz and >>>>> Matthew Luckie (WAND), published and presented at RIPE and >>>>> other conferences, shows a 2-3% failure rate to various popular >>>>> web sites. They did additional testing during World IPv6 Day, >>>>> but I haven't dug into those results yet. >>>>>=20 >>>>> -d >>>>>=20 >>>>>=20 >>>>> = ------------------------------------------------------------------- >> - >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6 >>>>> = ------------------------------------------------------------------- >> - >>>=20 >=20 From Fred.L.Templin@boeing.com Mon Jan 9 07:19:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A3221F8801 for ; Mon, 9 Jan 2012 07:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+pHheywHRoX for ; Mon, 9 Jan 2012 07:19:13 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C421F87FF for ; Mon, 9 Jan 2012 07:19:13 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q09FIx7I005375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jan 2012 07:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q09FIx7i019166; Mon, 9 Jan 2012 07:18:59 -0800 (PST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q09FIuVS019074 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jan 2012 07:18:57 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Mon, 9 Jan 2012 07:18:56 -0800 From: "Templin, Fred L" To: Fernando Gont , Florian Weimer Date: Mon, 9 Jan 2012 07:18:54 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczOtZPuHe/fJsiLRq2UNqsEwerdEgAK/nGw Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> In-Reply-To: <4F0AB553.2040400@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:19:14 -0000 =20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Fernando Gont > Sent: Monday, January 09, 2012 1:37 AM > To: Florian Weimer > Cc: Brian Haberman; ipv6@ietf.org; Brian E Carpenter > Subject: Re: Fragmentation-related security issues >=20 > On 01/09/2012 05:32 AM, Florian Weimer wrote: > >>> The ULA will have no meaning for ICMP messages that leave the > >>> administrative domain. > >> > >> That doesn't matter, > >=20 > > How do you implement BCP38 filters if the address lacks=20 > clear ownership? >=20 > Same thing would happen as it currently happens with ICMP=20 > error messages > sourced from private addresses: some get "mysteriously"=20 > dropped. -- i.e. > using ULAs for the source address of ICMPv6 messages seems like a very > bad idea. What I care most about is the value of the source address from the perspecive of the ICMP message recipient. I think no matter the source address scope, the recipinet cannot use the source address alone as a means of authenticating the ICMP, since there is no guarantee that BCP38 is universally implemented. Right? Thanks - Fred fred.l.templin@boeing.com =20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From fweimer@bfk.de Mon Jan 9 07:24:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C102A21F847A for ; Mon, 9 Jan 2012 07:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXXgzJquTS9d for ; Mon, 9 Jan 2012 07:24:28 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 928AF21F8494 for ; Mon, 9 Jan 2012 07:24:28 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RkH59-0002Uc-Aa; Mon, 09 Jan 2012 15:24:19 +0000 Received: by bfk.de with local id 1RkH59-00089s-4n; Mon, 09 Jan 2012 15:24:19 +0000 From: Florian Weimer To: "Templin\, Fred L" Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> Date: Mon, 09 Jan 2012 15:24:19 +0000 In-Reply-To: (Fred L. Templin's message of "Mon, 9 Jan 2012 07:18:54 -0800") Message-ID: <82vcokaogs.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:24:32 -0000 * Fred L. Templin: > What I care most about is the value of the source address > from the perspecive of the ICMP message recipient. I think > no matter the source address scope, the recipinet cannot > use the source address alone as a means of authenticating > the ICMP, since there is no guarantee that BCP38 is > universally implemented. Right? No, the recipient faces a different, even more difficult challenge: even if the source address is validated based on BCP38, the recipient doesn't know if the node with that address was actually on the path of the triggering packet and thus authorized to send the ICMP message. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Fred.L.Templin@boeing.com Mon Jan 9 07:35:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350D021F879E for ; Mon, 9 Jan 2012 07:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.584 X-Spam-Level: X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXLZ7uT9aPkR for ; Mon, 9 Jan 2012 07:34:59 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9355F21F8795 for ; Mon, 9 Jan 2012 07:34:59 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q09FYkcR028976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jan 2012 07:34:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q09FYjv5021813; Mon, 9 Jan 2012 07:34:46 -0800 (PST) Received: from XCH-NWHT-09.nw.nos.boeing.com (xch-nwht-09.nw.nos.boeing.com [130.247.25.115]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q09FYhMN021711 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jan 2012 07:34:43 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-09.nw.nos.boeing.com ([130.247.25.115]) with mapi; Mon, 9 Jan 2012 07:34:43 -0800 From: "Templin, Fred L" To: Florian Weimer Date: Mon, 9 Jan 2012 07:34:41 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczO4shrrRLhetbHQ/aYp7MvKkka7gAANYgA Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> <82vcokaogs.fsf@mid.bfk.de> In-Reply-To: <82vcokaogs.fsf@mid.bfk.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:35:00 -0000 =20 > -----Original Message----- > From: Florian Weimer [mailto:fweimer@bfk.de]=20 > Sent: Monday, January 09, 2012 7:24 AM > To: Templin, Fred L > Cc: Fernando Gont; Brian Haberman; ipv6@ietf.org; Brian E Carpenter > Subject: Re: Fragmentation-related security issues >=20 > * Fred L. Templin: >=20 > > What I care most about is the value of the source address > > from the perspecive of the ICMP message recipient. I think > > no matter the source address scope, the recipinet cannot > > use the source address alone as a means of authenticating > > the ICMP, since there is no guarantee that BCP38 is > > universally implemented. Right? >=20 > No, the recipient faces a different, even more difficult=20 > challenge: even > if the source address is validated based on BCP38, the=20 > recipient doesn't > know if the node with that address was actually on the path of the > triggering packet and thus authorized to send the ICMP message. Right - that is exactly why something like SEAL is useful. With SEAL, the ICMP recipient can know that the sender of the ICMP message is on-path, because the packet-in-error contains a digital signature that the recipient himself provided. That is why I said that the source address alone cannot be used to authenticate the ICMP message. Thanks - Fred fred.l.templin@boeing.com > --=20 > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra=DFe 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > = From fred@cisco.com Mon Jan 9 09:08:36 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDEAE11E80AB for ; Mon, 9 Jan 2012 09:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.338 X-Spam-Level: X-Spam-Status: No, score=-106.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS8eFNMo9Pje for ; Mon, 9 Jan 2012 09:08:34 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7DE11E8093 for ; Mon, 9 Jan 2012 09:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=630; q=dns/txt; s=iport; t=1326128914; x=1327338514; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=+/C5Vr/VkN5baUwp6LppgAOKqCfqRisejdLlfPHmueM=; b=EKSdHk/+SiR7fn3gJJWi5tWNrO0HsKq4i81JpcCJh/k4sodhdx/+LxSt jGCGa4cyM+67rv2Lp583NKBKTedcXmr84SaIRXAG056bbPWNNinLUlf6W g8u+arBRASr95EjtfTtaXrh3GRsVEfjibABCH+Npy5j4/P/tU6eHhRIaU 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOAdC0+rRDoI/2dsb2JhbABErFOBBYFyAQEBAwESASc/BQsLDjhXBjWHWJgCAZ5Ciy5jBIg5jFCFUY0J X-IronPort-AV: E=Sophos;i="4.71,480,1320624000"; d="scan'208";a="24508971" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 09 Jan 2012 17:08:34 +0000 Received: from stealth-10-32-244-220.cisco.com (stealth-10-32-244-220.cisco.com [10.32.244.220]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q09H8XEr010042; Mon, 9 Jan 2012 17:08:33 GMT Received: from [127.0.0.1] by stealth-10-32-244-220.cisco.com (PGP Universal service); Mon, 09 Jan 2012 09:08:34 -0800 X-PGP-Universal: processed; by stealth-10-32-244-220.cisco.com on Mon, 09 Jan 2012 09:08:34 -0800 Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F07C98C.7000107@si6networks.com> Date: Mon, 9 Jan 2012 09:08:03 -0800 Message-Id: <9329819E-68CE-4ECC-BC36-A03AD56023DF@cisco.com> References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <4F075B33.3090206@gmail.com> <4F07C98C.7000107@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:08:36 -0000 On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote: > I just said that PLPMTU has a long convergence time Frankly, that sounds like an implementation issue. If we're willing to = set IW=3D10, it seems like one should be able to send the initial burst, = or at least the first retransmission, with messages of several sizes and = see what works. In other words, if the MSS is 9K (I wish), send a 9K, a = 4K, a 1500 byte IP datagram (eg 1440 byte payload), and 1280. If we get = an Ack in the subsequent RTT acknowledging 8192 bytes, we learned = something, and if the only Ack acknowledges 1280, we learned something.= From Fred.L.Templin@boeing.com Mon Jan 9 10:09:15 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877BE11E8072 for ; Mon, 9 Jan 2012 10:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5y2NNnDa+7W for ; Mon, 9 Jan 2012 10:09:11 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 520D821F8486 for ; Mon, 9 Jan 2012 10:09:11 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q09I8wT8008132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jan 2012 10:08:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id q09I8wXE022036; Mon, 9 Jan 2012 10:08:58 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q09I8uQP021977 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 9 Jan 2012 10:08:56 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 9 Jan 2012 10:08:56 -0800 From: "Templin, Fred L" To: Florian Weimer Date: Mon, 9 Jan 2012 10:08:54 -0800 Subject: RE: Fragmentation-related security issues Thread-Topic: Fragmentation-related security issues Thread-Index: AczO4shrrRLhetbHQ/aYp7MvKkka7gAANYgAAAQ9V6A= Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> <82vcokaogs.fsf@mid.bfk.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 18:09:15 -0000 =20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On=20 > Behalf Of Templin, Fred L > Sent: Monday, January 09, 2012 7:35 AM > To: Florian Weimer > Cc: Brian Haberman; ipv6@ietf.org; Brian E Carpenter > Subject: RE: Fragmentation-related security issues >=20 > =20 >=20 > > -----Original Message----- > > From: Florian Weimer [mailto:fweimer@bfk.de]=20 > > Sent: Monday, January 09, 2012 7:24 AM > > To: Templin, Fred L > > Cc: Fernando Gont; Brian Haberman; ipv6@ietf.org; Brian E Carpenter > > Subject: Re: Fragmentation-related security issues > >=20 > > * Fred L. Templin: > >=20 > > > What I care most about is the value of the source address > > > from the perspecive of the ICMP message recipient. I think > > > no matter the source address scope, the recipinet cannot > > > use the source address alone as a means of authenticating > > > the ICMP, since there is no guarantee that BCP38 is > > > universally implemented. Right? > >=20 > > No, the recipient faces a different, even more difficult=20 > > challenge: even > > if the source address is validated based on BCP38, the=20 > > recipient doesn't > > know if the node with that address was actually on the path of the > > triggering packet and thus authorized to send the ICMP message. >=20 > Right - that is exactly why something like SEAL is useful. > With SEAL, the ICMP recipient can know that the sender of > the ICMP message is on-path, because the packet-in-error > contains a digital signature that the recipient himself > provided. That is why I said that the source address alone > cannot be used to authenticate the ICMP message. BTW, this is specified in Section 4.4.7 of http://tools.ietf.org/html/draft-templin-intarea-seal-42 (it does not appear in RFC5320, which will be deprecated by the RFC-to-be based on this new draft.) Thanks - Fred fred.l.templin@boieng.com > Thanks - Fred > fred.l.templin@boeing.com >=20 > > --=20 > > Florian Weimer > > BFK edv-consulting GmbH http://www.bfk.de/ > > Kriegsstra=DFe 100 tel: +49-721-96201-1 > > D-76133 Karlsruhe fax: +49-721-96201-99 > >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > = From brian.e.carpenter@gmail.com Mon Jan 9 12:40:51 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4FB821F8779 for ; Mon, 9 Jan 2012 12:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.483 X-Spam-Level: X-Spam-Status: No, score=-103.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IM5y8Oc3IK9R for ; Mon, 9 Jan 2012 12:40:51 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 424F621F8778 for ; Mon, 9 Jan 2012 12:40:51 -0800 (PST) Received: by obcuz6 with SMTP id uz6so5139718obc.31 for ; Mon, 09 Jan 2012 12:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LgVC7Kj4ajZSgNXMSNIMi27P37pDJPzrQz5m+jsKYO0=; b=p2zJnJyYdswqwm8egJbrWBpjPv7FLoEpLB6WTYI3B2pkw5knNyJxVTmKUDDAKD7gTi sFpPQFjZTGGfAmEWd9wAko1pbWDxwLYXJ6PJDaWc7dhZVQjz6bPyEAk/THGPbfnBlRyh yG7nAK9t9XK+3s+CUng1z/u2xKsf2UFRnY2Ag= Received: by 10.182.15.104 with SMTP id w8mr8473511obc.20.1326141650936; Mon, 09 Jan 2012 12:40:50 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id 1sm78187998obo.2.2012.01.09.12.40.47 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 12:40:49 -0800 (PST) Message-ID: <4F0B50CD.4020209@gmail.com> Date: Tue, 10 Jan 2012 09:40:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] References: <4F04A4D7.9060508@gmail.com> <4F04D11B.1010500@si6networks.com> <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <4F075B33.3090206@gmail.com> <4F07C98C.7000107@si6networks.com> <9329819E-68CE-4ECC-BC36-A03AD56023DF@cisco.com> In-Reply-To: <9329819E-68CE-4ECC-BC36-A03AD56023DF@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:40:51 -0000 On 2012-01-10 06:08, Fred Baker wrote: > On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote: > >> I just said that PLPMTU has a long convergence time > > Frankly, that sounds like an implementation issue. If we're willing to set IW=10, it seems like one should be able to send the initial burst, or at least the first retransmission, with messages of several sizes and see what works. In other words, if the MSS is 9K (I wish), send a 9K, a 4K, a 1500 byte IP datagram (eg 1440 byte payload), and 1280. If we get an Ack in the subsequent RTT acknowledging 8192 bytes, we learned something, and if the only Ack acknowledges 1280, we learned something. Right. And the point Fernando queried in my previous message was simply trying to say "happy eyeballs doesn't do this" - it will leave the user hanging if TCP connects but PMTUD or MSS negotiation fails. Brian From brian.e.carpenter@gmail.com Mon Jan 9 12:49:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861B521F8545 for ; Mon, 9 Jan 2012 12:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgwo3KHQHYYb for ; Mon, 9 Jan 2012 12:49:46 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF2521F853F for ; Mon, 9 Jan 2012 12:49:46 -0800 (PST) Received: by obcuz6 with SMTP id uz6so5153629obc.31 for ; Mon, 09 Jan 2012 12:49:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R9ODNPQsmiCXyVJN4bcQlqYyhMoXAl62Eh85IUrmP4E=; b=uszsfDtXaAtnknTt6D1XFbL+SK2XVG0BCexjc2syCVI/5wQik/pmd3ibFqEy9ZZusX SACOlBprNcfPfoZPVbdDUqOxLDODNE0nii4Wx5zTMdc0DU2uvBo3MqAkP2Zw7Gjr0M0L /gCU1fT3EKfR6ELjlE4BKRjiB+3CcwdDRhNrY= Received: by 10.182.111.36 with SMTP id if4mr16328676obb.38.1326142185733; Mon, 09 Jan 2012 12:49:45 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id f7sm5143273obx.11.2012.01.09.12.49.42 (version=SSLv3 cipher=OTHER); Mon, 09 Jan 2012 12:49:44 -0800 (PST) Message-ID: <4F0B52E3.9000003@gmail.com> Date: Tue, 10 Jan 2012 09:49:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> In-Reply-To: <4F0AB553.2040400@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 20:49:46 -0000 On 2012-01-09 22:37, Fernando Gont wrote: > On 01/09/2012 05:32 AM, Florian Weimer wrote: >>>> The ULA will have no meaning for ICMP messages that leave the >>>> administrative domain. >>> That doesn't matter, >> How do you implement BCP38 filters if the address lacks clear ownership? > > Same thing would happen as it currently happens with ICMP error messages > sourced from private addresses: some get "mysteriously" dropped. -- i.e. > using ULAs for the source address of ICMPv6 messages seems like a very > bad idea. It's a bad idea, but using link-local is even worse, because those MUST be dropped. I don't think ULAs will be stopped by ingress filters in the case that people over on v6ops were complaining about, where ICMP echo replies were sent by ISP-internal routers. ULAs will be stopped by ingress filters if a customer site uses them for ICMP replies. We agree that using a globally routeable address is best. Brian From fernando.gont.netbook.win@gmail.com Tue Jan 10 02:47:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656C21F86C1 for ; Tue, 10 Jan 2012 02:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-1.309, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTodNurO-CEd for ; Tue, 10 Jan 2012 02:47:25 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD65421F85BE for ; Tue, 10 Jan 2012 02:47:25 -0800 (PST) Received: by yhpp56 with SMTP id p56so1025950yhp.31 for ; Tue, 10 Jan 2012 02:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=08EULTzdzUnkzAMGK3ItSGhcDxffX1oS5uuBDgjeOzY=; b=NKY2CcAnbgMD0Gwm3/x76ei3wN4Kuz3/pcIN9yZEPfhj5GqigGnGjbzdidbXy8fEEJ RcIeF8N9egsz9f76lG1AmbYqoQNAleG/2RRNR7dIiO7mlavAd3YFI76cizWTMU0e4Jm7 kcEGsD3EBqdAnk9E4nBlJmZGv2+zWqvbjhtvQ= Received: by 10.236.193.70 with SMTP id j46mr25070855yhn.108.1326192445286; Tue, 10 Jan 2012 02:47:25 -0800 (PST) Received: from [192.168.123.102] ([190.48.234.182]) by mx.google.com with ESMTPS id u9sm173020511anh.20.2012.01.10.02.47.20 (version=SSLv3 cipher=OTHER); Tue, 10 Jan 2012 02:47:22 -0800 (PST) Sender: Fernando Gont Message-ID: <4F0B0AFA.3070207@gont.com.ar> Date: Mon, 09 Jan 2012 12:42:50 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: Fragmentation-related security issues References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 10:47:26 -0000 On 01/09/2012 12:18 PM, Templin, Fred L wrote: >> Same thing would happen as it currently happens with ICMP >> error messages >> sourced from private addresses: some get "mysteriously" >> dropped. -- i.e. >> using ULAs for the source address of ICMPv6 messages seems like a very >> bad idea. > > What I care most about is the value of the source address > from the perspecive of the ICMP message recipient. That depends on what you're using ICMP for. If it's for troubleshootinf (ping, traceroute, etc.), the Source Address has some value. If the ICMPs are meant to be processed by a transport layer (as in PMTUD), the the Source Address is of no value (it could correspond to the address of any intervenning router, and since virtually every router could be an "intervenning router", you cannoT "validate" the source address. > I think > no matter the source address scope, the recipinet cannot > use the source address alone as a means of authenticating > the ICMP, since there is no guarantee that BCP38 is > universally implemented. Right? Right. See RFC 5927. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jari.arkko@piuha.net Tue Jan 10 06:55:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC3A21F85AC for ; Tue, 10 Jan 2012 06:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSCgBoEi-8P1 for ; Tue, 10 Jan 2012 06:55:22 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1779321F85AA for ; Tue, 10 Jan 2012 06:55:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 89BE52CC38; Tue, 10 Jan 2012 16:55:20 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fKtYyKCUJtx; Tue, 10 Jan 2012 16:55:19 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 48BF02CC31; Tue, 10 Jan 2012 16:55:19 +0200 (EET) Message-ID: <4F0C5157.3020009@piuha.net> Date: Tue, 10 Jan 2012 16:55:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: draft-ietf-6man-3627-historic@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-3627-historic Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:55:22 -0000 I have reviewed this document, and as it obviously was ready to be moved = forward, asked for an IETF Last Call to be initiated. Thanks for writing = the document. Jari From iesg-secretary@ietf.org Tue Jan 10 08:00:48 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7521F8798; Tue, 10 Jan 2012 08:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxIryR3rrTFf; Tue, 10 Jan 2012 08:00:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB8B21F8776; Tue, 10 Jan 2012 08:00:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (RFC3627 to Historic status) to Informational RFC X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120110160047.14784.28475.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2012 08:00:47 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 16:00:48 -0000 The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'RFC3627 to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document moves RFC3627 (Use of /127 Prefix Length Between Routers Considered Harmful) to HISTORIC status to reflect the updated guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter- Router Links). While a standards track document already supersedes an informational document and therefore RFC6164 is the appropriate guidance to follow when the two documents are in conflict, this links the two documents so that it is clearer that the IETF has updated guidance on the matter. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ No IPR declarations have been submitted directly on this I-D. From Fred.L.Templin@boeing.com Tue Jan 10 09:53:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A630921F86AA for ; Tue, 10 Jan 2012 09:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js1I05hLIbmN for ; Tue, 10 Jan 2012 09:53:51 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD4B21F84E7 for ; Tue, 10 Jan 2012 09:53:51 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0AHsNVm029018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 10 Jan 2012 11:54:29 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q0AHrixj011691 for ; Tue, 10 Jan 2012 09:53:44 -0800 (PST) Received: from XCH-NWHT-03.nw.nos.boeing.com (xch-nwht-03.nw.nos.boeing.com [130.247.71.23]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0AHriDs011677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Tue, 10 Jan 2012 09:53:44 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-03.nw.nos.boeing.com ([130.247.71.23]) with mapi; Tue, 10 Jan 2012 09:53:44 -0800 From: "Templin, Fred L" To: "ipv6@ietf.org" Date: Tue, 10 Jan 2012 09:53:43 -0800 Subject: Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues) Thread-Topic: Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues) Thread-Index: AczO4shrrRLhetbHQ/aYp7MvKkka7gAANYgAAAQ9V6AAMsJUsA== Message-ID: References: <4F05110A.40108@gmail.com> <4F05253F.8060705@si6networks.com> <20120106.092736.505586056.he@uninett.no> <4F075905.1090109@gmail.com> <4F076052.6080800@innovationslab.net> <4F07625C.6090800@gmail.com> <82zkdxb7ih.fsf@mid.bfk.de> <4F0AB553.2040400@si6networks.com> <82vcokaogs.fsf@mid.bfk.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 17:53:52 -0000 Please see below for a pre-draft for using the Subnetwork Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension header. This extension header can be used by the source to defeat off-path spoofing of ICMPv6 error messages. When the source and destination share a secret symmetric key used for calculating the integrity check vector, the extension header also provides the destination with data origin authentication and anti-replay. Please send any comments to the list, Fred fred.l.templin@boeing.com --- cut here --- Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Informational January 10, 2012 Expires: July 13, 2012 The SEAL IPv6 Extension Header draft-templin-sealopt.txt Abstract The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 extension header. Namely, the SEAL header when used as an extension header contains a digital signature (inserted by the source) that covers the leading 128 bytes of the payload beginning with the SEAL header itself. The source can thereafter use the digital signature to verify that any ICMPv6 mesages received actually came from a router on the path. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 13, 2012. Copyright Notice Copyright (c) 2012 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 Templin Expires July 13, 2012 [Page 1] =0C Internet-Draft SEAL January 2012 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 2. SEAL IPv6 Extension Header . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Templin Expires July 13, 2012 [Page 2] =0C Internet-Draft SEAL January 2012 1. Introduction The Subnetwork Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] provides a mid-layer encapsulation designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the encapsulated payload corresponds to an ordinary transport layer protocol payload. It is in essence a close analogy of the GRE encapsulation format [RFC1701]. However, SEAL can also provide benefit when used as an IPv6 extension header [RFC2460]. Namely, the SEAL header when used as an IPv6 extension header contains a digital signature (inserted by the source) that covers the leading 128 bytes of the payload beginning with the SEAL header itself. The source can thereafter use the digital signature to verify that any ICMPv6 mesages received actually came from a router on the path. 2. SEAL IPv6 Extension Header The SEAL IPv6 extension header is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len =3D 2| SEAL Header (format TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Vector (ICV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SEAL IPv6 Extension Header Format Next Header (8) an 8-bit field that encodes the next header Internet Protocol number the same as for the IPv4 protocol and IPv6 next header fields. Next Header Length (8) an 8-bit length of the extension header measured in 8-byte words. Set to 2. SEAL Header (16) a 16-bit field that controls the operation of SEAL. Format TBD. Templin Expires July 13, 2012 [Page 3] =0C Internet-Draft SEAL January 2012 Identification (32) a 32-bit per-packet identification field. Set to a monotonically- incrementing 32-bit value for each SEAL packet transmitted, beginning with 0. Integrity Check Vector (ICV) (32) a 32-bit header integrity check value. Covers the leading 128 bytes of the packet beginning with the SEAL extension header (or up to the end of the packet). The value 128 is chosen so that at least the SEAL header as well as the inner packet network and transport layer headers are covered by the integrity check. The IPv6 source inserts a SEAL extension header whenever it wants to ensure that any resulting ICMPv6 error messages [RFC4443] came from a router on the path and not from an off-path attacker. When the source receives an ICMPv6 error message, it verifies that the ICV value is correct based on a secret hashing algorithm of its choosing. The source should choose a hashing algorithm that would make it virtually impossible for an off-path attacker to guess. 3. IANA Considerations The IANA is instructed to allocate an IPv6 extension header for SEAL. 4. Security Considerations The SEAL extension header can be used to verify that ICMPv6 messages wre delivered by an on-path router and not an off-path attacker. The header may also be used fro other authenticating purposes, e.g., if the destination shares a symmetric secret key with the source then the destination can verify that messages actually came from the source. The packet identification field can also be used for anti- replay sequencing. 5. Acknowledgments TBD. 6. References 6.1. Normative References [I-D.templin-intarea-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Templin Expires July 13, 2012 [Page 4] =0C Internet-Draft SEAL January 2012 Layer (SEAL)", draft-templin-intarea-seal-42 (work in progress), December 2011. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 6.2. Informative References [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires July 13, 2012 [Page 5] =0C= From internet-drafts@ietf.org Wed Jan 11 22:51:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE1E21F84E1; Wed, 11 Jan 2012 22:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-9auqThtlak; Wed, 11 Jan 2012 22:51:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65B521F8499; Wed, 11 Jan 2012 22:51:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-6man-exthdr-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120112065127.29423.13719.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2012 22:51:27 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 06:51:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Maintenance Working Group of the= IETF. Title : An uniform format for IPv6 extension headers Author(s) : Suresh Krishnan Apple Inc. Erik Kline James Hoagland Manav Bhatia Filename : draft-ietf-6man-exthdr-06.txt Pages : 8 Date : 2012-01-11 In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers if they are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-exthdr-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-exthdr-06.txt From sreenatha.b@huawei.com Wed Jan 11 20:42:42 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D6611E8085 for ; Wed, 11 Jan 2012 20:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnz5281OAI5q for ; Wed, 11 Jan 2012 20:42:39 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C216411E8072 for ; Wed, 11 Jan 2012 20:42:37 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXO002RW52TP2@szxga05-in.huawei.com> for ipv6@ietf.org; Thu, 12 Jan 2012 12:42:30 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXO00DBU52T0K@szxga05-in.huawei.com> for ipv6@ietf.org; Thu, 12 Jan 2012 12:42:29 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGG54127; Thu, 12 Jan 2012 12:42:27 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jan 2012 12:42:20 +0800 Received: from blrnshtipl6nc (10.18.1.36) by szxeml424-hub.china.huawei.com (10.82.67.163) with Microsoft SMTP Server id 14.1.323.3; Thu, 12 Jan 2012 12:42:15 +0800 Date: Thu, 12 Jan 2012 10:12:20 +0530 From: Sreenatha setty Subject: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) In-reply-to: X-Originating-IP: [10.18.1.36] To: fltemplin@acm.org Message-id: <92EEFBAB064A4B508D8BC51BB2EDE5DF@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4841 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_biNmD6wW8hkvRDQEj+qFKw)" Thread-index: AczPwPxFwR0OCeD1QD6yh2Vu5aRz1wBH+RQg X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 12 Jan 2012 03:37:41 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 04:48:51 -0000 --Boundary_(ID_biNmD6wW8hkvRDQEj+qFKw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Fred, I went through SEAL as an IPv6 extension header draft. I have some comments on the drafts. 1. SEAL IPv6 extension header functionality is similar to AH header functionality which is already standardized in RFC 2402(IP Authentication Header). AH header also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6 in RFC 2402] which is used to check the integrity of the packet. So what is the advantage of using SEAL header over AH header? 2. Security Consideration section of the draft contains two spelling mistakes: " 4. Security Considerations The SEAL extension header can be used to verify that ICMPv6 messages wre delivered by an on-path router and not an off-path attacker. The header may also be used fro other authenticating purposes, e.g., if the destination shares a symmetric secret key with the source then the destination can verify that messages actually came from the source. The packet identification field can also be used for anti- replay sequencing." Thanks & Regards, Sreenatha Setty sreenathabs@huawei.com -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ipv6-request@ietf.org Sent: Tuesday, January 10, 2012 11:24 PM To: ipv6@ietf.org Subject: ipv6 Digest, Vol 93, Issue 25 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ipv6 Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send ipv6 mailing list submissions to ipv6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipv6 or, via email, send a message with subject or body 'help' to ipv6-request@ietf.org You can reach the person managing the list at ipv6-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6 digest..." Today's Topics: 1. Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] (Brian E Carpenter) 2. Re: Fragmentation-related security issues (Brian E Carpenter) 3. Re: Fragmentation-related security issues (Fernando Gont) 4. AD review of draft-ietf-6man-3627-historic (Jari Arkko) 5. Last Call: (RFC3627 to Historic status) to Informational RFC (The IESG) 6. Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues) (Templin, Fred L) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Jan 2012 09:40:45 +1300 From: Brian E Carpenter To: Fred Baker Cc: "ipv6@ietf.org" Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] Message-ID: <4F0B50CD.4020209@gmail.com> Content-Type: text/plain; charset=UTF-8 On 2012-01-10 06:08, Fred Baker wrote: > On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote: > >> I just said that PLPMTU has a long convergence time > > Frankly, that sounds like an implementation issue. If we're willing to set IW=10, it seems like one should be able to send the initial burst, or at least the first retransmission, with messages of several sizes and see what works. In other words, if the MSS is 9K (I wish), send a 9K, a 4K, a 1500 byte IP datagram (eg 1440 byte payload), and 1280. If we get an Ack in the subsequent RTT acknowledging 8192 bytes, we learned something, and if the only Ack acknowledges 1280, we learned something. Right. And the point Fernando queried in my previous message was simply trying to say "happy eyeballs doesn't do this" - it will leave the user hanging if TCP connects but PMTUD or MSS negotiation fails. Brian ------------------------------ Message: 2 Date: Tue, 10 Jan 2012 09:49:39 +1300 From: Brian E Carpenter To: Fernando Gont Cc: Brian Haberman , ipv6@ietf.org Subject: Re: Fragmentation-related security issues Message-ID: <4F0B52E3.9000003@gmail.com> Content-Type: text/plain; charset=UTF-8 On 2012-01-09 22:37, Fernando Gont wrote: > On 01/09/2012 05:32 AM, Florian Weimer wrote: >>>> The ULA will have no meaning for ICMP messages that leave the >>>> administrative domain. >>> That doesn't matter, >> How do you implement BCP38 filters if the address lacks clear ownership? > > Same thing would happen as it currently happens with ICMP error messages > sourced from private addresses: some get "mysteriously" dropped. -- i.e. > using ULAs for the source address of ICMPv6 messages seems like a very > bad idea. It's a bad idea, but using link-local is even worse, because those MUST be dropped. I don't think ULAs will be stopped by ingress filters in the case that people over on v6ops were complaining about, where ICMP echo replies were sent by ISP-internal routers. ULAs will be stopped by ingress filters if a customer site uses them for ICMP replies. We agree that using a globally routeable address is best. Brian ------------------------------ Message: 3 Date: Mon, 09 Jan 2012 12:42:50 -0300 From: Fernando Gont To: "Templin, Fred L" Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter Subject: Re: Fragmentation-related security issues Message-ID: <4F0B0AFA.3070207@gont.com.ar> Content-Type: text/plain; charset=ISO-8859-1 On 01/09/2012 12:18 PM, Templin, Fred L wrote: >> Same thing would happen as it currently happens with ICMP >> error messages >> sourced from private addresses: some get "mysteriously" >> dropped. -- i.e. >> using ULAs for the source address of ICMPv6 messages seems like a very >> bad idea. > > What I care most about is the value of the source address > from the perspecive of the ICMP message recipient. That depends on what you're using ICMP for. If it's for troubleshootinf (ping, traceroute, etc.), the Source Address has some value. If the ICMPs are meant to be processed by a transport layer (as in PMTUD), the the Source Address is of no value (it could correspond to the address of any intervenning router, and since virtually every router could be an "intervenning router", you cannoT "validate" the source address. > I think > no matter the source address scope, the recipinet cannot > use the source address alone as a means of authenticating > the ICMP, since there is no guarantee that BCP38 is > universally implemented. Right? Right. See RFC 5927. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ------------------------------ Message: 4 Date: Tue, 10 Jan 2012 16:55:19 +0200 From: Jari Arkko To: draft-ietf-6man-3627-historic@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-3627-historic Message-ID: <4F0C5157.3020009@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have reviewed this document, and as it obviously was ready to be moved forward, asked for an IETF Last Call to be initiated. Thanks for writing the document. Jari ------------------------------ Message: 5 Date: Tue, 10 Jan 2012 08:00:47 -0800 From: The IESG To: IETF-Announce Cc: ipv6@ietf.org Subject: Last Call: (RFC3627 to Historic status) to Informational RFC Message-ID: <20120110160047.14784.28475.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="us-ascii" The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'RFC3627 to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document moves RFC3627 (Use of /127 Prefix Length Between Routers Considered Harmful) to HISTORIC status to reflect the updated guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter- Router Links). While a standards track document already supersedes an informational document and therefore RFC6164 is the appropriate guidance to follow when the two documents are in conflict, this links the two documents so that it is clearer that the IETF has updated guidance on the matter. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ No IPR declarations have been submitted directly on this I-D. ------------------------------ Message: 6 Date: Tue, 10 Jan 2012 09:53:43 -0800 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset="us-ascii" Please see below for a pre-draft for using the Subnetwork Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension header. This extension header can be used by the source to defeat off-path spoofing of ICMPv6 error messages. When the source and destination share a secret symmetric key used for calculating the integrity check vector, the extension header also provides the destination with data origin authentication and anti-replay. Please send any comments to the list, Fred fred.l.templin@boeing.com --- cut here --- Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Informational January 10, 2012 Expires: July 13, 2012 The SEAL IPv6 Extension Header draft-templin-sealopt.txt Abstract The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 extension header. Namely, the SEAL header when used as an extension header contains a digital signature (inserted by the source) that covers the leading 128 bytes of the payload beginning with the SEAL header itself. The source can thereafter use the digital signature to verify that any ICMPv6 mesages received actually came from a router on the path. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 13, 2012. Copyright Notice Copyright (c) 2012 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 Templin Expires July 13, 2012 [Page 1] Internet-Draft SEAL January 2012 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 2. SEAL IPv6 Extension Header . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Templin Expires July 13, 2012 [Page 2] Internet-Draft SEAL January 2012 1. Introduction The Subnetwork Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] provides a mid-layer encapsulation designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the encapsulated payload corresponds to an ordinary transport layer protocol payload. It is in essence a close analogy of the GRE encapsulation format [RFC1701]. However, SEAL can also provide benefit when used as an IPv6 extension header [RFC2460]. Namely, the SEAL header when used as an IPv6 extension header contains a digital signature (inserted by the source) that covers the leading 128 bytes of the payload beginning with the SEAL header itself. The source can thereafter use the digital signature to verify that any ICMPv6 mesages received actually came from a router on the path. 2. SEAL IPv6 Extension Header The SEAL IPv6 extension header is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len = 2| SEAL Header (format TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Vector (ICV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SEAL IPv6 Extension Header Format Next Header (8) an 8-bit field that encodes the next header Internet Protocol number the same as for the IPv4 protocol and IPv6 next header fields. Next Header Length (8) an 8-bit length of the extension header measured in 8-byte words. Set to 2. SEAL Header (16) a 16-bit field that controls the operation of SEAL. Format TBD. Templin Expires July 13, 2012 [Page 3] Internet-Draft SEAL January 2012 Identification (32) a 32-bit per-packet identification field. Set to a monotonically- incrementing 32-bit value for each SEAL packet transmitted, beginning with 0. Integrity Check Vector (ICV) (32) a 32-bit header integrity check value. Covers the leading 128 bytes of the packet beginning with the SEAL extension header (or up to the end of the packet). The value 128 is chosen so that at least the SEAL header as well as the inner packet network and transport layer headers are covered by the integrity check. The IPv6 source inserts a SEAL extension header whenever it wants to ensure that any resulting ICMPv6 error messages [RFC4443] came from a router on the path and not from an off-path attacker. When the source receives an ICMPv6 error message, it verifies that the ICV value is correct based on a secret hashing algorithm of its choosing. The source should choose a hashing algorithm that would make it virtually impossible for an off-path attacker to guess. 3. IANA Considerations The IANA is instructed to allocate an IPv6 extension header for SEAL. 4. Security Considerations The SEAL extension header can be used to verify that ICMPv6 messages wre delivered by an on-path router and not an off-path attacker. The header may also be used fro other authenticating purposes, e.g., if the destination shares a symmetric secret key with the source then the destination can verify that messages actually came from the source. The packet identification field can also be used for anti- replay sequencing. 5. Acknowledgments TBD. 6. References 6.1. Normative References [I-D.templin-intarea-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Templin Expires July 13, 2012 [Page 4] Internet-Draft SEAL January 2012 Layer (SEAL)", draft-templin-intarea-seal-42 (work in progress), December 2011. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 6.2. Informative References [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires July 13, 2012 [Page 5] ------------------------------ _______________________________________________ ipv6 mailing list ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 End of ipv6 Digest, Vol 93, Issue 25 ************************************ --Boundary_(ID_biNmD6wW8hkvRDQEj+qFKw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Fred,

      I went through SEAL as an IPv6 extension header draft. I have some comments on the drafts.

 

            1. SEAL IPv6 extension header functionality is similar to AH header functionality which is already standardized in RFC 2402(IP Authentication Header).  AH header also calculates the ICV of the packet

[Section 3.3.3.1.2  ICV Computation for IPv6 in RFC 2402] which is used to check the integrity of the packet. So what is the advantage of using SEAL header over AH header?

      2. Security Consideration section of the draft contains  two spelling mistakes:  

 

       " 4.  Security Considerations

 

          The SEAL extension header can be used to verify that ICMPv6 messages

          wre delivered by an on-path router and not an off-path attacker.  The

          header may also be used fro other authenticating purposes, e.g., if

          the destination shares a symmetric secret key with the source then

          the destination can verify that messages actually came from the

          source.  The packet identification field can also be used for anti-

          replay sequencing."

 

Thanks & Regards,

Sreenatha Setty

sreenathabs@huawei.com

 

 

 

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ipv6-request@ietf.org
Sent: Tuesday, January 10, 2012 11:24 PM
To: ipv6@ietf.org
Subject: ipv6 Digest, Vol 93, Issue 25

 

If you have received this digest without all the individual message

attachments you will need to update your digest options in your list

subscription.  To do so, go to

 

https://www.ietf.org/mailman/listinfo/ipv6

 

Click the 'Unsubscribe or edit options' button, log in, and set "Get

MIME or Plain Text Digests?" to MIME.  You can set this option

globally for all the list digests you receive at this point.

 

 

 

Send ipv6 mailing list submissions to

      ipv6@ietf.org

 

To subscribe or unsubscribe via the World Wide Web, visit

      https://www.ietf.org/mailman/listinfo/ipv6

or, via email, send a message with subject or body 'help' to

      ipv6-request@ietf.org

 

You can reach the person managing the list at

      ipv6-owner@ietf.org

 

When replying, please edit your Subject line so it is more specific

than "Re: Contents of ipv6 digest..."

 

 

Today's Topics:

 

   1. Re: Non-traditional PMTUD [was Re: Fragmentation-related

      security    issues] (Brian E Carpenter)

   2. Re: Fragmentation-related security issues (Brian E Carpenter)

   3. Re: Fragmentation-related security issues (Fernando Gont)

   4. AD review of draft-ietf-6man-3627-historic (Jari Arkko)

   5. Last Call: <draft-ietf-6man-3627-historic-01.txt> (RFC3627 to

      Historic status) to Informational RFC (The IESG)

   6. Pre-draft: SEAL as an IPv6 extension header (was:

      Fragmentation-related Security issues) (Templin, Fred L)

 

 

----------------------------------------------------------------------

 

Message: 1

Date: Tue, 10 Jan 2012 09:40:45 +1300

From: Brian E Carpenter <brian.e.carpenter@gmail.com>

To: Fred Baker <fred@cisco.com>

Cc: "ipv6@ietf.org" <ipv6@ietf.org>

Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related

      security    issues]

Message-ID: <4F0B50CD.4020209@gmail.com>

Content-Type: text/plain; charset=UTF-8

 

On 2012-01-10 06:08, Fred Baker wrote:

> On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote:

>

>> I just said that PLPMTU has a long convergence time

>

> Frankly, that sounds like an implementation issue. If we're willing to set IW=10, it seems like one should be able to send the initial burst, or at least the first retransmission, with messages of several sizes and see what works. In other words, if the MSS is 9K (I wish), send a 9K, a 4K, a 1500 byte IP datagram (eg 1440 byte payload), and 1280. If we get an Ack in the subsequent RTT acknowledging 8192 bytes, we learned something, and if the only Ack acknowledges 1280, we learned something.

 

Right. And the point Fernando queried in my previous message was

simply trying to say "happy eyeballs doesn't do this" - it will leave

the user hanging if TCP connects but PMTUD or MSS negotiation fails.

 

   Brian

 

 

------------------------------

 

Message: 2

Date: Tue, 10 Jan 2012 09:49:39 +1300

From: Brian E Carpenter <brian.e.carpenter@gmail.com>

To: Fernando Gont <fgont@si6networks.com>

Cc: Brian Haberman <brian@innovationslab.net>, ipv6@ietf.org

Subject: Re: Fragmentation-related security issues

Message-ID: <4F0B52E3.9000003@gmail.com>

Content-Type: text/plain; charset=UTF-8

 

On 2012-01-09 22:37, Fernando Gont wrote:

> On 01/09/2012 05:32 AM, Florian Weimer wrote:

>>>> The ULA will have no meaning for ICMP messages that leave the

>>>> administrative domain.

>>> That doesn't matter,

>> How do you implement BCP38 filters if the address lacks clear ownership?

>

> Same thing would happen as it currently happens with ICMP error messages

> sourced from private addresses: some get "mysteriously" dropped. -- i.e.

> using ULAs for the source address of ICMPv6 messages seems like a very

> bad idea.

 

It's a bad idea, but using link-local is even worse, because those

MUST be dropped.

 

I don't think ULAs will be stopped by ingress filters in the case that

people over on v6ops were complaining about, where ICMP echo replies

were sent by ISP-internal routers. ULAs will be stopped by ingress

filters if a customer site uses them for ICMP replies.

 

We agree that using a globally routeable address is best.

 

   Brian

 

 

------------------------------

 

Message: 3

Date: Mon, 09 Jan 2012 12:42:50 -0300

From: Fernando Gont <fernando@gont.com.ar>

To: "Templin, Fred L" <Fred.L.Templin@boeing.com>

Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org"

      <ipv6@ietf.org>,  Brian E Carpenter <brian.e.carpenter@gmail.com>

Subject: Re: Fragmentation-related security issues

Message-ID: <4F0B0AFA.3070207@gont.com.ar>

Content-Type: text/plain; charset=ISO-8859-1

 

On 01/09/2012 12:18 PM, Templin, Fred L wrote:

>> Same thing would happen as it currently happens with ICMP

>> error messages

>> sourced from private addresses: some get "mysteriously"

>> dropped. -- i.e.

>> using ULAs for the source address of ICMPv6 messages seems like a very

>> bad idea.

>

> What I care most about is the value of the source address

> from the perspecive of the ICMP message recipient.

 

That depends on what you're using ICMP for. If it's for troubleshootinf

(ping, traceroute, etc.), the Source Address has some value. If the

ICMPs are meant to be processed by a transport layer (as in PMTUD), the

the Source Address is of no value (it could correspond to the address of

any intervenning router, and since virtually every router could be an

"intervenning router", you cannoT "validate" the source address.

 

 

> I think

> no matter the source address scope, the recipinet cannot

> use the source address alone as a means of authenticating

> the ICMP, since there is no guarantee that BCP38 is

> universally implemented. Right?

 

Right. See RFC 5927.

 

Thanks,

--

Fernando Gont

e-mail: fernando@gont.com.ar || fgont@si6networks.com

PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

 

 

 

 

 

------------------------------

 

Message: 4

Date: Tue, 10 Jan 2012 16:55:19 +0200

From: Jari Arkko <jari.arkko@piuha.net>

To: draft-ietf-6man-3627-historic@tools.ietf.org,     IETF IPv6 Mailing

      List <ipv6@ietf.org>

Subject: AD review of draft-ietf-6man-3627-historic

Message-ID: <4F0C5157.3020009@piuha.net>

Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 

I have reviewed this document, and as it obviously was ready to be moved forward, asked for an IETF Last Call to be initiated. Thanks for writing the document.

 

Jari

 

 

 

 

------------------------------

 

Message: 5

Date: Tue, 10 Jan 2012 08:00:47 -0800

From: The IESG <iesg-secretary@ietf.org>

To: IETF-Announce <ietf-announce@ietf.org>

Cc: ipv6@ietf.org

Subject: Last Call: <draft-ietf-6man-3627-historic-01.txt> (RFC3627 to

      Historic status) to Informational RFC

Message-ID: <20120110160047.14784.28475.idtracker@ietfa.amsl.com>

Content-Type: text/plain; charset="us-ascii"

 

 

The IESG has received a request from the IPv6 Maintenance WG (6man) to

consider the following document:

- 'RFC3627 to Historic status'

  <draft-ietf-6man-3627-historic-01.txt> as an Informational RFC

 

The IESG plans to make a decision in the next few weeks, and solicits

final comments on this action. Please send substantive comments to the

ietf@ietf.org mailing lists by 2012-01-24. Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, please retain the

beginning of the Subject line to allow automated sorting.

 

Abstract

 

 

   This document moves RFC3627 (Use of /127 Prefix Length Between

   Routers Considered Harmful) to HISTORIC status to reflect the updated

   guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter-

   Router Links).  While a standards track document already supersedes

   an informational document and therefore RFC6164 is the appropriate

   guidance to follow when the two documents are in conflict, this links

   the two documents so that it is clearer that the IETF has updated

   guidance on the matter.

 

 

 

 

The file can be obtained via

http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/

 

IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/

 

 

No IPR declarations have been submitted directly on this I-D.

 

 

 

 

------------------------------

 

Message: 6

Date: Tue, 10 Jan 2012 09:53:43 -0800

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>

To: "ipv6@ietf.org" <ipv6@ietf.org>

Subject: Pre-draft: SEAL as an IPv6 extension header (was:

      Fragmentation-related Security issues)

Message-ID:

      <E1829B60731D1740BB7A0626B4FAF0A65C79362394@XCH-NW-01V.nw.nos.boeing.com>

     

Content-Type: text/plain; charset="us-ascii"

 

Please see below for a pre-draft for using the Subnetwork

Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension

header. This extension header can be used by the source to

defeat off-path spoofing of ICMPv6 error messages. When the

source and destination share a secret symmetric key used for

calculating the integrity check vector, the extension header

also provides the destination with data origin authentication

and anti-replay.

 

Please send any comments to the list,

 

Fred

fred.l.templin@boeing.com

 

--- cut here ---

 

 

 

 

Network Working Group                                    F. Templin, Ed.

Internet-Draft                              Boeing Research & Technology

Intended status: Informational                          January 10, 2012

Expires: July 13, 2012

 

 

                     The SEAL IPv6 Extension Header

                       draft-templin-sealopt.txt

 

Abstract

 

   The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a

   mid-layer header designed for the encapsulation of an inner network

   layer packet within outer network layer headers.  SEAL also supports

   a transport mode of operation, where the inner payload corresponds to

   an ordinary transport layer payload.  However, SEAL can also provide

   benefit when used as an IPv6 extension header.  Namely, the SEAL

   header when used as an extension header contains a digital signature

   (inserted by the source) that covers the leading 128 bytes of the

   payload beginning with the SEAL header itself.  The source can

   thereafter use the digital signature to verify that any ICMPv6

   mesages received actually came from a router on the path.

 

Status of this Memo

 

   This Internet-Draft is submitted in full conformance with the

   provisions of BCP 78 and BCP 79.

 

   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF).  Note that other groups may also distribute

   working documents as Internet-Drafts.  The list of current Internet-

   Drafts is at http://datatracker.ietf.org/drafts/current/.

 

   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."

 

   This Internet-Draft will expire on July 13, 2012.

 

Copyright Notice

 

   Copyright (c) 2012 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

 

 

 

Templin                   Expires July 13, 2012                 [Page 1]

 

Internet-Draft                    SEAL                      January 2012

 

 

   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

   2.  SEAL IPv6 Extension Header  . . . . . . . . . . . . . . . . . . 3

   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4

   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4

   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4

   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 4

     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 4

     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Templin                   Expires July 13, 2012                 [Page 2]

 

Internet-Draft                    SEAL                      January 2012

 

 

1.  Introduction

 

   The Subnetwork Encapsulation and Adaptation Layer (SEAL)

   [I-D.templin-intarea-seal] provides a mid-layer encapsulation

   designed for the encapsulation of an inner network layer packet

   within outer network layer headers.  SEAL also supports a transport

   mode of operation, where the encapsulated payload corresponds to an

   ordinary transport layer protocol payload.  It is in essence a close

   analogy of the GRE encapsulation format [RFC1701].

 

   However, SEAL can also provide benefit when used as an IPv6 extension

   header [RFC2460].  Namely, the SEAL header when used as an IPv6

   extension header contains a digital signature (inserted by the

   source) that covers the leading 128 bytes of the payload beginning

   with the SEAL header itself.  The source can thereafter use the

   digital signature to verify that any ICMPv6 mesages received actually

   came from a router on the path.

 

 

2.  SEAL IPv6 Extension Header

 

   The SEAL IPv6 extension header is formatted as follows:

 

       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Next Header  |Hdr Ext Len = 2|    SEAL Header (format TBD)   |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                         Identification                        |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                 Integrity Check Vector (ICV)                  |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |                          Reserved                             |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

                Figure 1: SEAL IPv6 Extension Header Format

 

   Next Header (8)  an 8-bit field that encodes the next header Internet

      Protocol number the same as for the IPv4 protocol and IPv6 next

      header fields.

 

   Next Header Length (8)  an 8-bit length of the extension header

      measured in 8-byte words.  Set to 2.

 

   SEAL Header (16)

      a 16-bit field that controls the operation of SEAL.  Format TBD.

 

 

 

 

 

Templin                   Expires July 13, 2012                 [Page 3]

 

Internet-Draft                    SEAL                      January 2012

 

 

   Identification (32)

      a 32-bit per-packet identification field.  Set to a monotonically-

      incrementing 32-bit value for each SEAL packet transmitted,

      beginning with 0.

 

   Integrity Check Vector (ICV) (32)

      a 32-bit header integrity check value.  Covers the leading 128

      bytes of the packet beginning with the SEAL extension header (or

      up to the end of the packet).  The value 128 is chosen so that at

      least the SEAL header as well as the inner packet network and

      transport layer headers are covered by the integrity check.

 

   The IPv6 source inserts a SEAL extension header whenever it wants to

   ensure that any resulting ICMPv6 error messages [RFC4443] came from a

   router on the path and not from an off-path attacker.  When the

   source receives an ICMPv6 error message, it verifies that the ICV

   value is correct based on a secret hashing algorithm of its choosing.

   The source should choose a hashing algorithm that would make it

   virtually impossible for an off-path attacker to guess.

 

 

3.  IANA Considerations

 

   The IANA is instructed to allocate an IPv6 extension header for SEAL.

 

 

4.  Security Considerations

 

   The SEAL extension header can be used to verify that ICMPv6 messages

   wre delivered by an on-path router and not an off-path attacker.  The

   header may also be used fro other authenticating purposes, e.g., if

   the destination shares a symmetric secret key with the source then

   the destination can verify that messages actually came from the

   source.  The packet identification field can also be used for anti-

   replay sequencing.

 

 

5.  Acknowledgments

 

   TBD.

 

 

6.  References

 

6.1.  Normative References

 

   [I-D.templin-intarea-seal]

              Templin, F., "The Subnetwork Encapsulation and Adaptation

 

 

 

Templin                   Expires July 13, 2012                 [Page 4]

 

Internet-Draft                    SEAL                      January 2012

 

 

              Layer (SEAL)", draft-templin-intarea-seal-42 (work in

              progress), December 2011.

 

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6

              (IPv6) Specification", RFC 2460, December 1998.

 

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control

              Message Protocol (ICMPv6) for the Internet Protocol

              Version 6 (IPv6) Specification", RFC 4443, March 2006.

 

6.2.  Informative References

 

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic

              Routing Encapsulation (GRE)", RFC 1701, October 1994.

 

 

Author's Address

 

   Fred L. Templin (editor)

   Boeing Research & Technology

   P.O. Box 3707

   Seattle, WA  98124

   USA

 

   Email: fltemplin@acm.org

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Templin                   Expires July 13, 2012                 [Page 5]

 

 

------------------------------

 

_______________________________________________

ipv6 mailing list

ipv6@ietf.org

https://www.ietf.org/mailman/listinfo/ipv6

 

 

End of ipv6 Digest, Vol 93, Issue 25

************************************

--Boundary_(ID_biNmD6wW8hkvRDQEj+qFKw)-- From fgont@si6networks.com Thu Jan 12 06:18:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B97A21F85DB for ; Thu, 12 Jan 2012 06:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.448 X-Spam-Level: X-Spam-Status: No, score=-1.448 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8rpz1GDVUKE for ; Thu, 12 Jan 2012 06:18:16 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id F22DB21F85DA for ; Thu, 12 Jan 2012 06:18:15 -0800 (PST) Received: from [190.48.225.51] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RlLTk-0000td-S6; Thu, 12 Jan 2012 15:18:09 +0100 Message-ID: <4F0EDCF9.2060507@si6networks.com> Date: Thu, 12 Jan 2012 10:15:37 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: Fwd: New Version of draft-gont-6man-nd-extension-headers-02.txt X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 14:18:16 -0000 Folks, I have posted a revision of draft-gont-6man-nd-extension-headers. It is available at: http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-02.txt This version hopefully addresses the feedback I received over the last few months, and what seemed to be the consensus of the discussions that we had on the mailing list. Any feedback will be very appreciated. Thanks so much! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-6man-nd-extension-headers-02.txt Date: Thu, 12 Jan 2012 04:51:23 -0800 From: internet-drafts@ietf.org To: fernando@gont.com.ar CC: fernando@gont.com.ar A new version of I-D, draft-gont-6man-nd-extension-headers-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-nd-extension-headers Revision: 02 Title: Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery Creation date: 2012-01-12 WG ID: Individual Submission Number of pages: 13 Abstract: This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and provides advice such that the aforementioned security implications are mitigated. The IETF Secretariat From Fred.L.Templin@boeing.com Thu Jan 12 10:39:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B582E21F8664 for ; Thu, 12 Jan 2012 10:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODY4vatyMMMi for ; Thu, 12 Jan 2012 10:39:03 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0083821F8508 for ; Thu, 12 Jan 2012 10:39:02 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0CIclH0008777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jan 2012 10:38:52 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q0CIckRg002063; Thu, 12 Jan 2012 10:38:46 -0800 (PST) Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0CIcjp2002038 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 12 Jan 2012 10:38:46 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-11.nw.nos.boeing.com ([130.247.25.114]) with mapi; Thu, 12 Jan 2012 10:38:45 -0800 From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Date: Thu, 12 Jan 2012 10:38:44 -0800 Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Thread-Topic: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Thread-Index: AczPwPxFwR0OCeD1QD6yh2Vu5aRz1wBH+RQgAB0COTA= Message-ID: References: <92EEFBAB064A4B508D8BC51BB2EDE5DF@china.huawei.com> In-Reply-To: <92EEFBAB064A4B508D8BC51BB2EDE5DF@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF16BXCHNW01Vnwnos_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Jan 2012 10:42:58 -0800 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 18:39:06 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF16BXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sreenatha, Since posting my message, I have submitted an actual draft that deprecates the list-posted pre-draft: https://datatracker.ietf.org/doc/draft-templin-sealopt/ The posted version makes the observation that the source can use the SEAL option either in coordination with the destination (in which case the sourc= e includes a digital signature that the destination can verify) or independen= tly from the destination (in which case the source can include any type of signature it likes). Your question seems to stem from the former case: > 1. SEAL IPv6 extension header functionality is similar to AH header funct= ionality > which is already standardized in RFC 2402(IP Authentication Header). AH h= eader > also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation = for IPv6 > in RFC 2402] which is used to check the integrity of the packet. So what = is the > advantage of using SEAL header over AH header? When the source and destination share a secret key used for digital signatu= re calculation and verification, it is true that SEAL somewhat resembles AH. However, the SEAL source only calculates the digital signature over the lea= ding 128 bytes of the packet beginning with the SEAL header itself. So, unlike A= H, the digital signature does not cover the entire packet and does not cover a pseudo-header of the IPv6 header. This has two important implications. First, when a router on the path needs= to drop an IPv6 packet with a SEAL option and return an ICMP error message, th= e packet-in-error within the ICMP will include enough of the leading portion = of the SEAL packet so that the source can verify that the ICMP was generated by an on-path router. The same is not true for AH, since the AH ICV covers the en= tire packet, and the packet-in-error field within the ICMP message may not inclu= de the entire packet. Second, the digital signature will remain valid even if = the IPv6 header is subject to network address translation. >From the perspective of the destination, the digital signature provides a l= ight weight data origin authentication and integrity checking capability for the leading 128 bytes of the packet. The Identification field additionally prov= ides the destination with a means to detect replayed packets. Note that this provides less authentication assurance than AH, since a middlebox on the path could alter the "tail" of the packet beyond the leading 128 bytes. But= , it defeats off-path spoofing attacks. Note again that, when the source and destination are not engaged in a digital signing and verification relationship, the source could sign the message any way it wants, e.g., by writing a constant or time-varying nonce. In that case, the destination would be vulnerable to an off-path attacker guessing the nonce and hence should not use the nonce as a data origin authentication signature. Thanks - Fred PS The number 128 was chosen so that enough of the packet would be included to provide sufficient inter-packet diversity in calculating the di= gital signature. However, I could also see an arguement for a smaller number, e.g., 64, 80, 96, etc. ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sre= enatha setty Sent: Wednesday, January 11, 2012 8:42 PM To: fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-= related Security issues) Hi Fred, I went through SEAL as an IPv6 extension header draft. I have some co= mments on the drafts. 1. SEAL IPv6 extension header functionality is similar to AH he= ader functionality which is already standardized in RFC 2402(IP Authenticat= ion Header). AH header also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6 in RFC 2402] which is used to = check the integrity of the packet. So what is the advantage of using SEAL h= eader over AH header? 2. Security Consideration section of the draft contains two spelling= mistakes: " 4. Security Considerations The SEAL extension header can be used to verify that ICMPv6 messa= ges wre delivered by an on-path router and not an off-path attacker. = The header may also be used fro other authenticating purposes, e.g., = if the destination shares a symmetric secret key with the source the= n the destination can verify that messages actually came from the source. The packet identification field can also be used for ant= i- replay sequencing." Thanks & Regards, Sreenatha Setty sreenathabs@huawei.com -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ipv= 6-request@ietf.org Sent: Tuesday, January 10, 2012 11:24 PM To: ipv6@ietf.org Subject: ipv6 Digest, Vol 93, Issue 25 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/ipv6 Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send ipv6 mailing list submissions to ipv6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/ipv6 or, via email, send a message with subject or body 'help' to ipv6-request@ietf.org You can reach the person managing the list at ipv6-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ipv6 digest..." Today's Topics: 1. Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] (Brian E Carpenter) 2. Re: Fragmentation-related security issues (Brian E Carpenter) 3. Re: Fragmentation-related security issues (Fernando Gont) 4. AD review of draft-ietf-6man-3627-historic (Jari Arkko) 5. Last Call: (RFC3627 to Historic status) to Informational RFC (The IESG) 6. Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues) (Templin, Fred L) ---------------------------------------------------------------------- Message: 1 Date: Tue, 10 Jan 2012 09:40:45 +1300 From: Brian E Carpenter To: Fred Baker Cc: "ipv6@ietf.org" Subject: Re: Non-traditional PMTUD [was Re: Fragmentation-related security issues] Message-ID: <4F0B50CD.4020209@gmail.com> Content-Type: text/plain; charset=3DUTF-8 On 2012-01-10 06:08, Fred Baker wrote: > On Jan 6, 2012, at 8:26 PM, Fernando Gont wrote: > >> I just said that PLPMTU has a long convergence time > > Frankly, that sounds like an implementation issue. If we're willing to se= t IW=3D10, it seems like one should be able to send the initial burst, or a= t least the first retransmission, with messages of several sizes and see wh= at works. In other words, if the MSS is 9K (I wish), send a 9K, a 4K, a 150= 0 byte IP datagram (eg 1440 byte payload), and 1280. If we get an Ack in th= e subsequent RTT acknowledging 8192 bytes, we learned something, and if the= only Ack acknowledges 1280, we learned something. Right. And the point Fernando queried in my previous message was simply trying to say "happy eyeballs doesn't do this" - it will leave the user hanging if TCP connects but PMTUD or MSS negotiation fails. Brian ------------------------------ Message: 2 Date: Tue, 10 Jan 2012 09:49:39 +1300 From: Brian E Carpenter To: Fernando Gont Cc: Brian Haberman , ipv6@ietf.org Subject: Re: Fragmentation-related security issues Message-ID: <4F0B52E3.9000003@gmail.com> Content-Type: text/plain; charset=3DUTF-8 On 2012-01-09 22:37, Fernando Gont wrote: > On 01/09/2012 05:32 AM, Florian Weimer wrote: >>>> The ULA will have no meaning for ICMP messages that leave the >>>> administrative domain. >>> That doesn't matter, >> How do you implement BCP38 filters if the address lacks clear ownership? > > Same thing would happen as it currently happens with ICMP error messages > sourced from private addresses: some get "mysteriously" dropped. -- i.e. > using ULAs for the source address of ICMPv6 messages seems like a very > bad idea. It's a bad idea, but using link-local is even worse, because those MUST be dropped. I don't think ULAs will be stopped by ingress filters in the case that people over on v6ops were complaining about, where ICMP echo replies were sent by ISP-internal routers. ULAs will be stopped by ingress filters if a customer site uses them for ICMP replies. We agree that using a globally routeable address is best. Brian ------------------------------ Message: 3 Date: Mon, 09 Jan 2012 12:42:50 -0300 From: Fernando Gont To: "Templin, Fred L" Cc: Brian Haberman , "ipv6@ietf.org" , Brian E Carpenter Subject: Re: Fragmentation-related security issues Message-ID: <4F0B0AFA.3070207@gont.com.ar> Content-Type: text/plain; charset=3DISO-8859-1 On 01/09/2012 12:18 PM, Templin, Fred L wrote: >> Same thing would happen as it currently happens with ICMP >> error messages >> sourced from private addresses: some get "mysteriously" >> dropped. -- i.e. >> using ULAs for the source address of ICMPv6 messages seems like a very >> bad idea. > > What I care most about is the value of the source address > from the perspecive of the ICMP message recipient. That depends on what you're using ICMP for. If it's for troubleshootinf (ping, traceroute, etc.), the Source Address has some value. If the ICMPs are meant to be processed by a transport layer (as in PMTUD), the the Source Address is of no value (it could correspond to the address of any intervenning router, and since virtually every router could be an "intervenning router", you cannoT "validate" the source address. > I think > no matter the source address scope, the recipinet cannot > use the source address alone as a means of authenticating > the ICMP, since there is no guarantee that BCP38 is > universally implemented. Right? Right. See RFC 5927. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ------------------------------ Message: 4 Date: Tue, 10 Jan 2012 16:55:19 +0200 From: Jari Arkko To: draft-ietf-6man-3627-historic@tools.ietf.org, IETF IPv6 Mailing List Subject: AD review of draft-ietf-6man-3627-historic Message-ID: <4F0C5157.3020009@piuha.net> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed I have reviewed this document, and as it obviously was ready to be moved fo= rward, asked for an IETF Last Call to be initiated. Thanks for writing the = document. Jari ------------------------------ Message: 5 Date: Tue, 10 Jan 2012 08:00:47 -0800 From: The IESG To: IETF-Announce Cc: ipv6@ietf.org Subject: Last Call: (RFC3627 to Historic status) to Informational RFC Message-ID: <20120110160047.14784.28475.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"us-ascii" The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'RFC3627 to Historic status' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document moves RFC3627 (Use of /127 Prefix Length Between Routers Considered Harmful) to HISTORIC status to reflect the updated guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter- Router Links). While a standards track document already supersedes an informational document and therefore RFC6164 is the appropriate guidance to follow when the two documents are in conflict, this links the two documents so that it is clearer that the IETF has updated guidance on the matter. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-3627-historic/ No IPR declarations have been submitted directly on this I-D. ------------------------------ Message: 6 Date: Tue, 10 Jan 2012 09:53:43 -0800 From: "Templin, Fred L" To: "ipv6@ietf.org" Subject: Pre-draft: SEAL as an IPv6 extension header (was: Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Please see below for a pre-draft for using the Subnetwork Encapsulation and Adaptation Layer (SEAL) as an IPv6 extension header. This extension header can be used by the source to defeat off-path spoofing of ICMPv6 error messages. When the source and destination share a secret symmetric key used for calculating the integrity check vector, the extension header also provides the destination with data origin authentication and anti-replay. Please send any comments to the list, Fred fred.l.templin@boeing.com --- cut here --- Network Working Group F. Templin, Ed. Internet-Draft Boeing Research & Technology Intended status: Informational January 10, 2012 Expires: July 13, 2012 The SEAL IPv6 Extension Header draft-templin-sealopt.txt Abstract The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 extension header. Namely, the SEAL header when used as an extension header contains a digital signature (inserted by the source) that covers the leading 128 bytes of the payload beginning with the SEAL header itself. The source can thereafter use the digital signature to verify that any ICMPv6 mesages received actually came from a router on the path. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 13, 2012. Copyright Notice Copyright (c) 2012 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 Templin Expires July 13, 2012 [Page 1] Internet-Draft SEAL January 2012 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 2. SEAL IPv6 Extension Header . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Templin Expires July 13, 2012 [Page 2] Internet-Draft SEAL January 2012 1. Introduction The Subnetwork Encapsulation and Adaptation Layer (SEAL) [I-D.templin-intarea-seal] provides a mid-layer encapsulation designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the encapsulated payload corresponds to an ordinary transport layer protocol payload. It is in essence a close analogy of the GRE encapsulation format [RFC1701]. However, SEAL can also provide benefit when used as an IPv6 extension header [RFC2460]. Namely, the SEAL header when used as an IPv6 extension header contains a digital signature (inserted by the source) that covers the leading 128 bytes of the payload beginning with the SEAL header itself. The source can thereafter use the digital signature to verify that any ICMPv6 mesages received actually came from a router on the path. 2. SEAL IPv6 Extension Header The SEAL IPv6 extension header is formatted as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Hdr Ext Len =3D 2| SEAL Header (format TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Vector (ICV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SEAL IPv6 Extension Header Format Next Header (8) an 8-bit field that encodes the next header Internet Protocol number the same as for the IPv4 protocol and IPv6 next header fields. Next Header Length (8) an 8-bit length of the extension header measured in 8-byte words. Set to 2. SEAL Header (16) a 16-bit field that controls the operation of SEAL. Format TBD. Templin Expires July 13, 2012 [Page 3] Internet-Draft SEAL January 2012 Identification (32) a 32-bit per-packet identification field. Set to a monotonically- incrementing 32-bit value for each SEAL packet transmitted, beginning with 0. Integrity Check Vector (ICV) (32) a 32-bit header integrity check value. Covers the leading 128 bytes of the packet beginning with the SEAL extension header (or up to the end of the packet). The value 128 is chosen so that at least the SEAL header as well as the inner packet network and transport layer headers are covered by the integrity check. The IPv6 source inserts a SEAL extension header whenever it wants to ensure that any resulting ICMPv6 error messages [RFC4443] came from a router on the path and not from an off-path attacker. When the source receives an ICMPv6 error message, it verifies that the ICV value is correct based on a secret hashing algorithm of its choosing. The source should choose a hashing algorithm that would make it virtually impossible for an off-path attacker to guess. 3. IANA Considerations The IANA is instructed to allocate an IPv6 extension header for SEAL. 4. Security Considerations The SEAL extension header can be used to verify that ICMPv6 messages wre delivered by an on-path router and not an off-path attacker. The header may also be used fro other authenticating purposes, e.g., if the destination shares a symmetric secret key with the source then the destination can verify that messages actually came from the source. The packet identification field can also be used for anti- replay sequencing. 5. Acknowledgments TBD. 6. References 6.1. Normative References [I-D.templin-intarea-seal] Templin, F., "The Subnetwork Encapsulation and Adaptation Templin Expires July 13, 2012 [Page 4] Internet-Draft SEAL January 2012 Layer (SEAL)", draft-templin-intarea-seal-42 (work in progress), December 2011. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 6.2. Informative References [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 USA Email: fltemplin@acm.org Templin Expires July 13, 2012 [Page 5] ------------------------------ _______________________________________________ ipv6 mailing list ipv6@ietf.org https://www.ietf.org/mailman/listinfo/ipv6 End of ipv6 Digest, Vol 93, Issue 25 ************************************ --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF16BXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sreenatha,
 
Since posting my message, I have= submitted=20 an actual draft that=20 deprecates
the list-posted pre-draft:
 
https://datatracker.ietf.org/doc/draft-templin-sealopt/=
 
The posted version makes the obs= ervation=20 that the source can use the=20 SEAL
option either in coordination wi= th the destination (in which case the=20 source
includes a digital signature that the destination can = verify) or=20 independently
from the destination (in which case the source can include any type of
signature it likes). Your questi= on seems=20 to stem from the former case:
 
>=20 1. SEAL IPv6 extension header functionality is similar to AH header= =20 functionality
>=20 which is already standardized in RFC 2402(IP Authentication Header).= AH header
>=20 also calculates the ICV of the packet=20 [Section 3.3.3.1.2 ICV Computation for IPv6
>=20 in RFC 2402] which is used to check the integrity of the packet. So = what=20 is the
>=20 advantage of using SEAL header over AH header?
 
When the=20 source and destination share a secret key used for digital signature
calculation=20 and verification, it is true that SEAL somewhat resembles=20 AH.
However, the=20 SEAL source only calculates the digital signature over the=20 leading
128 bytes of=20 the packet beginning with the SEAL header itself. So, unlike AH,
the digital=20 signature does not cover the entire packet and does not cover=20 a
pseudo-header of the IPv6 header.
 
This has two=20 important implications. First, when a router on the path needs to
drop an IPv6=20 packet with a SEAL option and return an ICMP error message,=20 the
packet-in-error=20 = within=20 = the ICMP=20 will include enough of the leading portion =20 = of=20 the
SEAL=20 = packet so=20 = that the=20 source can verify that the ICMP was generated=20 = by=20 an
on-path=20 router. The same is not true for AH, since the AH ICV covers th= e=20 entire
packet, and=20 the packet-in-error field within the ICMP message may not=20 include
the entire=20 packet.=20 Second, the digital signature will remain valid even if= the=20 IPv6
header is subject to= network=20 address translation.
 
From the=20 perspective of the destination, the digital signature provides a=20 light
weight data=20 origin authentication and integrity checking capability for=20 the
leading=20 = 128 bytes=20 of the packet. The Identification field additionally provides
the=20 destination with a means to detect replayed packets. No= te that=20 this
provides=20 = less=20 authentication assurance than AH, since a middlebox on the
path could=20 = alter the=20 "tail" of the packet beyond = the leading 128 bytes. But,
it defeats=20 = off-path=20 spoofing attacks.
 
Note again=20 that, when the source and destination are not engaged in a
digital=20 signing and verification relationship, the source could sign=20 the
message any=20 way it wants, e.g., by writing a constant or time-varying
nonce. In=20 that case, the destination would be vulnerable to an=20 off-path
attacker=20 guessing the nonce and hence should not use the nonce as
a data=20 origin authentication signature.
 
Thanks -=20 Fred
 
PS The=20 number 128 was chosen so that enough of the packet would be
included to=20 provide sufficient inter-packet diversity in calculating the=20 digital
signature.=20 However, I could also see an arguement for a smaller number,<= /DIV>
e.g., 64,=20 80, 96, etc.
 
From: ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org] On Behalf Of Sreenatha=20 setty
Sent: Wednesday, January 11, 2012 8:42 PM
To:=20 fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE:Pre-d= raft:=20 SEAL as an IPv6 extension header (was:Fragmentation-related Security=20 issues)

Hi Fred,

      I went through S= EAL as=20 an IPv6 extension header draft. I have some comments on the=20 drafts.

 

        = ;   =20 1. SEAL IPv6 extens= ion=20 header functionality is similar to AH header functionality which is alrea= dy=20 standardized in RFC 2402(IP Authentication Header).  AH header also= =20 calculates the ICV of the packet

[Section 3.3.3.1.2&= nbsp;=20 ICV Computation for IPv6 in RFC 2402] whi= ch is=20 used to check the integrity of the packet. So what is the advantage of us= ing=20 SEAL header over AH header?

   &= nbsp; =20 2. Security Consideration section of the draft contains  two spellin= g=20 mistakes:  

 

 =20      " 4.  Security=20 Considerations

 

  =20        The SEAL extension header can b= e=20 used to verify that ICMPv6 messages

  =20        wre delivered b= y an=20 on-path router and not an off-path attacker. =20 The

  =20        header may also be used fro=20 other authenticating purposes, e.g., if

  =20        the destination shares a symmet= ric=20 secret key with the source then

  =20        the destination can verify that= =20 messages actually came from the

  =20        source.  The packet=20 identification field can also be used for anti-<= /P>

  =20        replay=20 sequencing."

 

Thanks &=20 Regards,

Sreenatha=20 Setty

sreenathabs@huawei.= com

 

 

 

-----Original Message-----
From:=20 ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of=20 ipv6-request@ietf.org
Sent: Tuesday, January 10, 2012 11:24 PM
To:= =20 ipv6@ietf.org
Subject: ipv6 Digest, Vol 93, Issue 25

 

If you have received this digest without all th= e=20 individual message

attachments you will need to update your digest= =20 options in your list

subscription.  To do so, go to=20

 

https://www.ietf.org/mailman/listinfo/ipv6=

 

Click the 'Unsubscribe or edit options' button,= log=20 in, and set "Get

MIME or Plain Text Digests?" to MIME.  You= can=20 set this option

globally for all the list digests you receive a= t this=20 point.

 

 

 

Send ipv6 mailing list submissions=20 to

     =20 ipv6@ietf.org

 

To subscribe or unsubscribe via the World Wide = Web,=20 visit

     =20 https://www.ietf.org/mailman/listinfo/ipv6

or, via email, send a message with subject or b= ody=20 'help' to

     =20 ipv6-request@ietf.org

 

You can reach the person managing the list=20 at

     =20 ipv6-owner@ietf.org

 

When replying, please edit your Subject line so= it is=20 more specific

than "Re: Contents of ipv6=20 digest..."

 

 

Today's Topics:

 

   1. Re: Non-traditional PMTUD [was = Re:=20 Fragmentation-related

     =20 security    issues] (Brian E=20 Carpenter)

   2. Re: Fragmentation-related secur= ity=20 issues (Brian E Carpenter)

   3. Re: Fragmentation-related secur= ity=20 issues (Fernando Gont)

   4. AD review of=20 draft-ietf-6man-3627-historic (Jari Arkko)

   5. Last Call:=20 <draft-ietf-6man-3627-historic-01.txt> (RFC3627=20 to

      Historic status)= to=20 Informational RFC (The IESG)

   6. Pre-draft: SEAL as an IPv6 exte= nsion=20 header (was:

      Fragmentation-re= lated=20 Security issues) (Templin, Fred L)

 

 

-----------------------------------------------= -----------------------

 

Message: 1

Date: Tue, 10 Jan 2012 09:40:45=20 +1300

From: Brian E Carpenter=20 <brian.e.carpenter@gmail.com>

To: Fred Baker=20 <fred@cisco.com>

Cc: "ipv6@ietf.org"=20 <ipv6@ietf.org>

Subject: Re: Non-traditional PMTUD [was Re:=20 Fragmentation-related

     =20 security    issues]

Message-ID:=20 <4F0B50CD.4020209@gmail.com>

Content-Type: text/plain;=20 charset=3DUTF-8

 

On 2012-01-10 06:08, Fred Baker=20 wrote:

> On Jan 6, 2012, at 8:26 PM, Fernando Gont= =20 wrote:

>

>> I just said that PLPMTU has a long=20 convergence time

>

> Frankly, that sounds like an implementatio= n=20 issue. If we're willing to set IW=3D10, it seems like one should be able = to send=20 the initial burst, or at least the first retransmission, with messages of= =20 several sizes and see what works. In other words, if the MSS is 9K (I wis= h),=20 send a 9K, a 4K, a 1500 byte IP datagram (eg 1440 byte payload), and 1280= . If=20 we get an Ack in the subsequent RTT acknowledging 8192 bytes, we learned= =20 something, and if the only Ack acknowledges 1280, we learned=20 something.

 

Right. And the point Fernando queried in my pre= vious=20 message was

simply trying to say "happy eyeballs doesn't do= this"=20 - it will leave

the user hanging if TCP connects but PMTUD or M= SS=20 negotiation fails.

 

   Brian

 

 

------------------------------

 

Message: 2

Date: Tue, 10 Jan 2012 09:49:39=20 +1300

From: Brian E Carpenter=20 <brian.e.carpenter@gmail.com>

To: Fernando Gont=20 <fgont@si6networks.com>

Cc: Brian Haberman <brian@innovationslab.net= >,=20 ipv6@ietf.org

Subject: Re: Fragmentation-related security=20 issues

Message-ID:=20 <4F0B52E3.9000003@gmail.com>

Content-Type: text/plain;=20 charset=3DUTF-8

 

On 2012-01-09 22:37, Fernando Gont=20 wrote:

> On 01/09/2012 05:32 AM, Florian Weimer=20 wrote:

>>>> The ULA will have no meaning f= or ICMP=20 messages that leave the

>>>> administrative=20 domain.

>>> That doesn't=20 matter,

>> How do you implement BCP38 filters if = the=20 address lacks clear ownership?

>

> Same thing would happen as it currently ha= ppens=20 with ICMP error messages

> sourced from private addresses: some get=20 "mysteriously" dropped. -- i.e.

> using ULAs for the source address of ICMPv= 6=20 messages seems like a very

> bad idea.

 

It's a bad idea, but using link-local is even w= orse,=20 because those

MUST be dropped.

 

I don't think ULAs will be stopped by ingress f= ilters=20 in the case that

people over on v6ops were complaining about, wh= ere=20 ICMP echo replies

were sent by ISP-internal routers. ULAs will be= =20 stopped by ingress

filters if a customer site uses them for ICMP=20 replies.

 

We agree that using a globally routeable addres= s is=20 best.

 

   Brian

 

 

------------------------------

 

Message: 3

Date: Mon, 09 Jan 2012 12:42:50=20 -0300

From: Fernando Gont=20 <fernando@gont.com.ar>

To: "Templin, Fred L"=20 <Fred.L.Templin@boeing.com>

Cc: Brian Haberman <brian@innovationslab.net= >,=20 "ipv6@ietf.org"

     =20 <ipv6@ietf.org>,  Brian E Carpenter=20 <brian.e.carpenter@gmail.com>

Subject: Re: Fragmentation-related security=20 issues

Message-ID:=20 <4F0B0AFA.3070207@gont.com.ar>

Content-Type: text/plain;=20 charset=3DISO-8859-1

 

On 01/09/2012 12:18 PM, Templin, Fred L=20 wrote:

>> Same thing would happen as it currentl= y=20 happens with ICMP

>> error messages

>> sourced from private addresses: some g= et=20 "mysteriously"

>> dropped. -- i.e.

>> using ULAs for the source address of I= CMPv6=20 messages seems like a very

>> bad idea.

>

> What I care most about is the value of the= source=20 address

> from the perspecive of the ICMP message=20 recipient.

 

That depends on what you're using ICMP for. If = it's=20 for troubleshootinf

(ping, traceroute, etc.), the Source Address ha= s some=20 value. If the

ICMPs are meant to be processed by a transport = layer=20 (as in PMTUD), the

the Source Address is of no value (it could cor= respond=20 to the address of

any intervenning router, and since virtually ev= ery=20 router could be an

"intervenning router", you cannoT "validate" th= e=20 source address.

 

 

> I think

> no matter the source address scope, the re= cipinet=20 cannot

> use the source address alone as a means of= =20 authenticating

> the ICMP, since there is no guarantee that= BCP38=20 is

> universally implemented.=20 Right?

 

Right. See RFC 5927.

 

Thanks,

--

Fernando Gont

e-mail: fernando@gont.com.ar ||=20 fgont@si6networks.com

PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 = 96EE=20 A9EF D076 FFF1

 

 

 

 

 

------------------------------

 

Message: 4

Date: Tue, 10 Jan 2012 16:55:19=20 +0200

From: Jari Arkko=20 <jari.arkko@piuha.net>

To: draft-ietf-6man-3627-historic@tools.ietf.or= g,=20     IETF IPv6 Mailing

      List=20 <ipv6@ietf.org>

Subject: AD review of=20 draft-ietf-6man-3627-historic

Message-ID:=20 <4F0C5157.3020009@piuha.net>

Content-Type: text/plain; charset=3DISO-8859-1;= =20 format=3Dflowed

 

I have reviewed this document, and as it obviou= sly was=20 ready to be moved forward, asked for an IETF Last Call to be initiated. T= hanks=20 for writing the document.

 

Jari

 

 

 

 

------------------------------

 

Message: 5

Date: Tue, 10 Jan 2012 08:00:47=20 -0800

From: The IESG=20 <iesg-secretary@ietf.org>

To: IETF-Announce=20 <ietf-announce@ietf.org>

Cc: ipv6@ietf.org

Subject: Last Call:=20 <draft-ietf-6man-3627-historic-01.txt> (RFC3627=20 to

      Historic status)= to=20 Informational RFC

Message-ID:=20 <20120110160047.14784.28475.idtracker@ietfa.amsl.com>

Content-Type: text/plain;=20 charset=3D"us-ascii"

 

 

The IESG has received a request from the IPv6=20 Maintenance WG (6man) to

consider the following=20 document:

- 'RFC3627 to Historic=20 status'

  <draft-ietf-6man-3627-historic-01.txt= > as=20 an Informational RFC

 

The IESG plans to make a decision in the next f= ew=20 weeks, and solicits

final comments on this action. Please send subs= tantive=20 comments to the

ietf@ietf.org mailing lists by 2012-01-24.=20 Exceptionally, comments may be

sent to iesg@ietf.org instead. In either case, = please=20 retain the

beginning of the Subject line to allow automate= d=20 sorting.

 

Abstract

 

 

   This document moves RFC3627 (Use o= f /127=20 Prefix Length Between

   Routers Considered Harmful) to HIS= TORIC=20 status to reflect the updated

   guidance contained in RFC6164 (Usi= ng=20 127-Bit IPv6 Prefixes on Inter-

   Router Links).  While a stand= ards=20 track document already supersedes

   an informational document and ther= efore=20 RFC6164 is the appropriate

   guidance to follow when the two do= cuments=20 are in conflict, this links

   the two documents so that it is cl= earer=20 that the IETF has updated

   guidance on the=20 matter.

 

 

 

 

The file can be obtained=20 via

http://datatracker.ietf.org/doc/draft-ietf-6man= -3627-historic/

 

IESG discussion can be tracked=20 via

http://datatracker.ietf.org/doc/draft-ietf-6man= -3627-historic/

 

 

No IPR declarations have been submitted directl= y on=20 this I-D.

 

 

 

 

------------------------------

 

Message: 6

Date: Tue, 10 Jan 2012 09:53:43=20 -0800

From: "Templin, Fred L"=20 <Fred.L.Templin@boeing.com>

To: "ipv6@ietf.org"=20 <ipv6@ietf.org>

Subject: Pre-draft: SEAL as an IPv6 extension h= eader=20 (was:

      Fragmentation-re= lated=20 Security issues)

Message-ID:

     =20 <E1829B60731D1740BB7A0626B4FAF0A65C79362394@XCH-NW-01V.nw.nos.boeing.c= om>

     =20

Content-Type: text/plain;=20 charset=3D"us-ascii"

 

Please see below for a pre-draft for using the= =20 Subnetwork

Encapsulation and Adaptation Layer (SEAL) as an= IPv6=20 extension

header. This extension header can be used by th= e=20 source to

defeat off-path spoofing of ICMPv6 error messag= es.=20 When the

source and destination share a secret symmetric= key=20 used for

calculating the integrity check vector, the ext= ension=20 header

also provides the destination with data origin= =20 authentication

and anti-replay.

 

Please send any comments to the=20 list,

 

Fred

fred.l.templin@boeing.com

 

--- cut here ---

 

 

 

 

Network Working=20 Group           &n= bsp;            = ;           =20 F. Templin, Ed.

Internet-Draft     &nb= sp;     =20             &= nbsp;     Boeing=20 Research & Technology

Intended status:=20 Informational          =             &nb= sp;  =20 January 10, 2012

Expires: July 13, 2012=

 

 

        = ;            =20 The SEAL IPv6 Extension Header

        = ;            &n= bsp; =20 draft-templin-sealopt.txt

 

Abstract

 

   The Subnetwork Encapsulation and=20 Adaptation Layer (SEAL) provides a

   mid-layer header designed for the= =20 encapsulation of an inner network

   layer packet within outer network = layer=20 headers.  SEAL also supports

   a transport mode of operation, whe= re the=20 inner payload corresponds to

   an ordinary transport layer=20 payload.  However, SEAL can also provide

   benefit when used as an IPv6 exten= sion=20 header.  Namely, the SEAL

   header when used as an extension h= eader=20 contains a digital signature

   (inserted by the source) that cove= rs the=20 leading 128 bytes of the

   payload beginning with the SEAL he= ader=20 itself.  The source can

   thereafter use the digital signatu= re to=20 verify that any ICMPv6

   mesages received actually came fro= m a=20 router on the path.

 

Status of this Memo

 

   This Internet-Draft is submitted i= n full=20 conformance with the

   provisions of BCP 78 and BCP=20 79.

 

   Internet-Drafts are working docume= nts of=20 the Internet Engineering

   Task Force (IETF).  Note that= other=20 groups may also distribute

   working documents as=20 Internet-Drafts.  The list of current=20 Internet-

   Drafts is at=20 http://datatracker.ietf.org/drafts/current/.

 

   Internet-Drafts are draft document= s valid=20 for a maximum of six months

   and may be updated, replaced, or=20 obsoleted by other documents at any

   time.  It is inappropriate to= use=20 Internet-Drafts as reference

   material or to cite them other tha= n as=20 "work in progress."

 

   This Internet-Draft will expire on= July=20 13, 2012.

 

Copyright Notice

 

   Copyright (c) 2012 IETF Trust and = the=20 persons identified as the

   document authors.  All rights= =20 reserved.

 

   This document is subject to BCP 78= and=20 the IETF Trust's Legal

   Provisions Relating to IETF=20 Documents

   (http://trustee.ietf.org/license-i= nfo) in=20 effect on the date of

 

 

 

Templin      &nbs= p;           =20 Expires July 13,=20 2012           &nb= sp;    =20 [Page 1]

=

 

Internet-Draft     &nb= sp;            =  =20 SEAL           &nb= sp;         =20 January 2012

 

 

   publication of this document. = ;=20 Please review these documents

   carefully, as they describe your r= ights=20 and restrictions with respect

   to this document.  Code Compo= nents=20 extracted from this document must

   include Simplified BSD License tex= t as=20 described in Section 4.e of

   the Trust Legal Provisions and are= =20 provided without warranty as

   described in the Simplified BSD=20 License.

 

 

Table of Contents

 

   1.  Introduction  . . . = . . . .=20 . . . . . . . . . . . . . . . . . . 3

   2.  SEAL IPv6 Extension Heade= r =20 . . . . . . . . . . . . . . . . . . 3

   3.  IANA Considerations . . .= . . .=20 . . . . . . . . . . . . . . . . 4

   4.  Security Considerations .= . . .=20 . . . . . . . . . . . . . . . . 4

   5.  Acknowledgments . . . . .= . . .=20 . . . . . . . . . . . . . . . . 4

   6.  References  . . . . = . . . .=20 . . . . . . . . . . . . . . . . . . 4

     6.1.  Normative=20 References  . . . . . . . . . . . . . . . . . . .=20 4

     6.2.  Informative= =20 References  . . . . . . . . . . . . . . . . . .=20 5

   Author's Address  . . . . . .= . . .=20 . . . . . . . . . . . . . . . . 5

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Templin      &nbs= p;           =20 Expires July 13,=20 2012           &nb= sp;    =20 [Page 2]

=

 

Internet-Draft     &nb= sp;            =  =20 SEAL           &nb= sp;         =20 January 2012

 

 

1.  Introduction<= /P>

 

   The Subnetwork Encapsulation and=20 Adaptation Layer (SEAL)

   [I-D.templin-intarea-seal] provide= s a=20 mid-layer encapsulation

   designed for the encapsulation of = an=20 inner network layer packet

   within outer network layer headers= . =20 SEAL also supports a transport

   mode of operation, where the encap= sulated=20 payload corresponds to an

   ordinary transport layer protocol= =20 payload.  It is in essence a close

   analogy of the GRE encapsulation f= ormat=20 [RFC1701].

 

   However, SEAL can also provide ben= efit=20 when used as an IPv6 extension

   header [RFC2460].  Namely, th= e SEAL=20 header when used as an IPv6

   extension header contains a digita= l=20 signature (inserted by the

   source) that covers the leading 12= 8 bytes=20 of the payload beginning

   with the SEAL header itself. = The=20 source can thereafter use the

   digital signature to verify that a= ny=20 ICMPv6 mesages received actually

   came from a router on the=20 path.

 

 

2.  SEAL IPv6 Extension=20 Header

 

   The SEAL IPv6 extension header is= =20 formatted as follows:

 

      =20 0            =       =20 1            =       =20 2            =       =20 3

       0 1 2 3 4 = 5 6 7 8=20 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Next=20 Header  |Hdr Ext Len =3D 2|    SEAL Header (format=20 TBD)   |

     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     =20 |            =             =20 Identification          = ;            &n= bsp;=20 |

     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     =20 |            =     =20 Integrity Check Vector=20 (ICV)           &n= bsp;     =20 |

     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     =20 |            =             &nb= sp;=20 Reserved           = ;            &n= bsp;    =20 |

     =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

        = ;       =20 Figure 1: SEAL IPv6 Extension Header Format

 

   Next Header (8)  an 8-bit fie= ld that=20 encodes the next header Internet

      Protocol number = the=20 same as for the IPv4 protocol and IPv6 next

      header=20 fields.

 

   Next Header Length (8)  an 8-= bit=20 length of the extension header

      measured in 8-by= te=20 words.  Set to 2.

 

   SEAL Header=20 (16)

      a 16-bit field t= hat=20 controls the operation of SEAL.  Format TBD.

 

 

 

 

 

Templin      &nbs= p;           =20 Expires July 13,=20 2012           &nb= sp;    =20 [Page 3]

=

 

Internet-Draft     &nb= sp;            =  =20 SEAL           &nb= sp;         =20 January 2012

 

 

   Identification=20 (32)

      a 32-bit per-pac= ket=20 identification field.  Set to a=20 monotonically-

      incrementing 32-= bit=20 value for each SEAL packet transmitted,

      beginning with=20 0.

 

   Integrity Check Vector (ICV)=20 (32)

      a 32-bit header= =20 integrity check value.  Covers the leading=20 128

      bytes of the pac= ket=20 beginning with the SEAL extension header (or

      up to the end of= the=20 packet).  The value 128 is chosen so that at

      least the SEAL h= eader=20 as well as the inner packet network and

      transport layer = headers=20 are covered by the integrity check.

 

   The IPv6 source inserts a SEAL ext= ension=20 header whenever it wants to

   ensure that any resulting ICMPv6 e= rror=20 messages [RFC4443] came from a

   router on the path and not from an= =20 off-path attacker.  When the

   source receives an ICMPv6 error me= ssage,=20 it verifies that the ICV

   value is correct based on a secret= =20 hashing algorithm of its choosing.

   The source should choose a hashing= =20 algorithm that would make it

   virtually impossible for an off-pa= th=20 attacker to guess.

 

 

3.  IANA=20 Considerations

 

   The IANA is instructed to allocate= an=20 IPv6 extension header for SEAL.

 

 

4.  Security=20 Considerations

 

   The SEAL extension header can be u= sed to=20 verify that ICMPv6 messages

   wre delivered by an on-path router= and=20 not an off-path attacker.  The

   header may also be used fro other= =20 authenticating purposes, e.g., if

   the destination shares a symmetric= secret=20 key with the source then

   the destination can verify that me= ssages=20 actually came from the

   source.  The packet identific= ation=20 field can also be used for anti-

   replay=20 sequencing.

 

 

5.  Acknowledgments

 

   TBD.

 

 

6.  References

 

6.1.  Normative=20 References

 

  =20 [I-D.templin-intarea-seal]

        = ;     =20 Templin, F., "The Subnetwork Encapsulation and=20 Adaptation

 

 

 

Templin      &nbs= p;           =20 Expires July 13,=20 2012           &nb= sp;    =20 [Page 4]

=

 

Internet-Draft     &nb= sp;            =  =20 SEAL           &nb= sp;         =20 January 2012

 

 

        = ;     =20 Layer (SEAL)", draft-templin-intarea-seal-42 (work=20 in

        = ;     =20 progress), December 2011.

 

   [RFC2460]  Deering, S. and R.= =20 Hinden, "Internet Protocol, Version 6

        = ;     =20 (IPv6) Specification", RFC 2460, December 1998.<= /P>

 

   [RFC4443]  Conta, A., Deering= , S.,=20 and M. Gupta, "Internet Control

        = ;     =20 Message Protocol (ICMPv6) for the Internet=20 Protocol

        = ;     =20 Version 6 (IPv6) Specification", RFC 4443, March=20 2006.

 

6.2.  Informative=20 References

 

   [RFC1701]  Hanks, S., Li, T.,= =20 Farinacci, D., and P. Traina, "Generic

        = ;     =20 Routing Encapsulation (GRE)", RFC 1701, October=20 1994.

 

 

Author's Address

 

   Fred L. Templin=20 (editor)

   Boeing Research &=20 Technology

   P.O. Box=20 3707

   Seattle, WA&nbs= p;=20 98124

   USA=

 

   Email:=20 fltemplin@acm.org

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Templin      &nbs= p;           =20 Expires July 13,=20 2012           &nb= sp;    =20 [Page 5]

=

 

 

------------------------------

 

_______________________________________________=

ipv6 mailing list

ipv6@ietf.org

https://www.ietf.org/mailman/listinfo/ipv6=

 

 

End of ipv6 Digest, Vol 93, Issue=20 25

************************************=

--_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF16BXCHNW01Vnwnos_-- From cgrundemann@gmail.com Thu Jan 12 12:24:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C511E8088 for ; Thu, 12 Jan 2012 12:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4r6od0hVQWG for ; Thu, 12 Jan 2012 12:24:50 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E97F11E8083 for ; Thu, 12 Jan 2012 12:24:50 -0800 (PST) Received: by dajz8 with SMTP id z8so1749403daj.31 for ; Thu, 12 Jan 2012 12:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vZc6hkDUhJ/U+ETHSk9HMKmZehjLWiOupFjld4/VySQ=; b=chh6clhgsgS6EoEAsAB+jMj/bNWEec9LzemcoqSCnRqFvWZ0zIChWUfSkCc992OIzN anZgVVew5aRhtEAYn7Y3lfym9OMQLfm/o/jBAT0vh7BAO+rHos09aNxhtv3gtoNsinwT Gj2F30jby/CP4ywREG3WpFdZKAZJw+cELemkY= MIME-Version: 1.0 Received: by 10.68.117.7 with SMTP id ka7mr11050644pbb.21.1326399889915; Thu, 12 Jan 2012 12:24:49 -0800 (PST) Received: by 10.143.82.18 with HTTP; Thu, 12 Jan 2012 12:24:49 -0800 (PST) In-Reply-To: References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> Date: Thu, 12 Jan 2012 13:24:49 -0700 Message-ID: Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt From: Chris Grundemann To: Tim Chown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6man Mailing List , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:24:51 -0000 On Fri, Dec 16, 2011 at 03:49, Tim Chown wrote: > Well, there are two questions here. > > One is whether the WG believes the update as described in draft-ietf-6man= -rfc3484-revise-05 is correct and complete. =A0I have not seen (yet) any si= gnificant technical concerns raised. =A0The last of those were discussed an= d (we believe) resolved in Quebec. =A0Are there any more? It appears that there is general agreement here, with possibly a few technical/content nits that probably need to be sorted in a final revision, raised by Dave and documented in message: https://www.ietf.org/mail-archive/web/ipv6/current/msg14984.html > The other is whether the WG believes we should publish an update, or a co= mplete fresh version of RFC3484. =A0This was discussed previously in the WG= and the update path preferred. =A0If a fresh version is now deemed more ap= propriate, I am fine to work on that with the other authors if required. My understanding is that there is also general agreement here; that this should be published as an update (after being re-organized a bit) now, and then followed up with a replace (bis) I-D. As I have previously stated; the changes in this update are needed and are time-sensitive, the sooner this update can become an RFC the better. > We just need a decision so we can progress this - it's been so close to r= elease for a long time. =A0Many of the changes in the update have been impl= emented in a number of platforms already. Agreed, let's get this done! =3D) Cheers, ~Chris PS - I don't want to step on any toes here, but I'd be happy to take a stab at a revision based on the current feedback if the authors would like, I could probably get it done by the end of next week, possibly sooner. > Tim > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --=20 @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From sreenatha.b@huawei.com Thu Jan 12 20:45:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4C621F852B for ; Thu, 12 Jan 2012 20:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5kM4ONHzV-u for ; Thu, 12 Jan 2012 20:45:48 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D19FA21F852A for ; Thu, 12 Jan 2012 20:45:47 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP00FIGZVO6M@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 13 Jan 2012 12:45:24 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXP00HU8ZVO1C@szxga05-in.huawei.com> for ipv6@ietf.org; Fri, 13 Jan 2012 12:45:24 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK50039; Fri, 13 Jan 2012 12:45:21 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 12:45:12 +0800 Received: from blrnshtipl6nc (10.18.1.36) by szxeml406-hub.china.huawei.com (10.82.67.93) with Microsoft SMTP Server id 14.1.323.3; Fri, 13 Jan 2012 12:45:14 +0800 Date: Fri, 13 Jan 2012 10:15:27 +0530 From: Sreenatha setty Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) X-Originating-IP: [10.18.1.36] To: fltemplin@acm.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4841 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_fYgWva3uZF/LVrygWdUuoQ)" Thread-index: AczRritoWWU5eFohSYun74sigPsbGw== X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 13 Jan 2012 00:56:38 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 04:45:49 -0000 --Boundary_(ID_fYgWva3uZF/LVrygWdUuoQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Fred, In the draft, the behavior of destination node in processing the SEAL header is need to be cleared. If nodes are not exchanging symmetric key and it received SEAL extension header packet and the packet is not ICMPv6 error packet, how destination node should process the SEAL header? It should simply ignore the SEAL header and go to next header processing or it should try to validate the signature in SEAL header? Thanks - Sreenatha ----------------------------------------------------- From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Cc: "ipv6@ietf.org" Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset="us-ascii" Hi Sreenatha, Since posting my message, I have submitted an actual draft that deprecates the list-posted pre-draft: https://datatracker.ietf.org/doc/draft-templin-sealopt/ The posted version makes the observation that the source can use the SEAL option either in coordination with the destination (in which case the source includes a digital signature that the destination can verify) or independently from the destination (in which case the source can include any type of signature it likes). Your question seems to stem from the former case: > 1. SEAL IPv6 extension header functionality is similar to AH header functionality > which is already standardized in RFC 2402(IP Authentication Header). AH header > also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6 > in RFC 2402] which is used to check the integrity of the packet. So what is the > advantage of using SEAL header over AH header? When the source and destination share a secret key used for digital signature calculation and verification, it is true that SEAL somewhat resembles AH. However, the SEAL source only calculates the digital signature over the leading 128 bytes of the packet beginning with the SEAL header itself. So, unlike AH, the digital signature does not cover the entire packet and does not cover a pseudo-header of the IPv6 header. This has two important implications. First, when a router on the path needs to drop an IPv6 packet with a SEAL option and return an ICMP error message, the packet-in-error within the ICMP will include enough of the leading portion of the SEAL packet so that the source can verify that the ICMP was generated by an on-path router. The same is not true for AH, since the AH ICV covers the entire packet, and the packet-in-error field within the ICMP message may not include the entire packet. Second, the digital signature will remain valid even if the IPv6 header is subject to network address translation. ------------------------------ Message: 3 Message-ID: ight weight data origin authentication and integrity checking capability for the leading 128 bytes of the packet. The Identification field additionally prov= ides the destination with a means to detect replayed packets. Note that this provides less authentication assurance than AH, since a middlebox on the path could alter the "tail" of the packet beyond the leading 128 bytes. But= , it defeats off-path spoofing attacks. Note again that, when the source and destination are not engaged in a digital signing and verification relationship, the source could sign the message any way it wants, e.g., by writing a constant or time-varying nonce. In that case, the destination would be vulnerable to an off-path attacker guessing the nonce and hence should not use the nonce as a data origin authentication signature. Thanks - Fred PS The number 128 was chosen so that enough of the packet would be included to provide sufficient inter-packet diversity in calculating the di= gital signature. However, I could also see an arguement for a smaller number, e.g., 64, 80, 96, etc. --Boundary_(ID_fYgWva3uZF/LVrygWdUuoQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Fred,

      In the draft, the behavior of destination node in processing the SEAL header is need to be cleared.  If nodes are not exchanging symmetric key and it received SEAL extension header packet and the packet is not ICMPv6 error packet, how destination node should process the SEAL header? It should simply ignore the SEAL header and go to next header processing or it should try to validate the signature in SEAL header?

 

Thanks - Sreenatha

     

-----------------------------------------------------

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>

To: Sreenatha setty <sreenatha.b@huawei.com>, "fltemplin@acm.org"

      <fltemplin@acm.org>

Cc: "ipv6@ietf.org" <ipv6@ietf.org>

Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header

      (was:Fragmentation-related Security issues)

Message-ID:

      <E1829B60731D1740BB7A0626B4FAF0A65C793AF16B@XCH-NW-01V.nw.nos.boeing.com>

     

Content-Type: text/plain; charset="us-ascii"

 

Hi Sreenatha,

 

Since posting my message, I have submitted an actual draft that deprecates

the list-posted pre-draft:

 

https://datatracker.ietf.org/doc/draft-templin-sealopt/

 

The posted version makes the observation that the source can use the SEAL

option either in coordination with the destination (in which case the source

includes a digital signature that the destination can verify) or independently

from the destination (in which case the source can include any type of

signature it likes). Your question seems to stem from the former case:

 

> 1. SEAL IPv6 extension header functionality is similar to AH header functionality

> which is already standardized in RFC 2402(IP Authentication Header). AH header

> also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6

> in RFC 2402] which is used to check the integrity of the packet. So what is the

> advantage of using SEAL header over AH header?

 

When the source and destination share a secret key used for digital signature

calculation and verification, it is true that SEAL somewhat resembles AH.

However, the SEAL source only calculates the digital signature over the leading

128 bytes of the packet beginning with the SEAL header itself. So, unlike AH,

the digital signature does not cover the entire packet and does not cover a

pseudo-header of the IPv6 header.

 

This has two important implications. First, when a router on the path needs to

drop an IPv6 packet with a SEAL option and return an ICMP error message, the

packet-in-error within the ICMP will include enough of the leading portion  of the

SEAL packet so that the source can verify that the ICMP was generated by an

on-path router. The same is not true for AH, since the AH ICV covers the entire

packet, and the packet-in-error field within the ICMP message may not include

the entire packet. Second, the digital signature will remain valid even if the IPv6

header is subject to network address translation.

 

------------------------------

 

Message: 3

Message-ID: <mailman.1071.1326393779.3200.ipv6@ietf.org>

 

ight

weight data origin authentication and integrity checking capability for the

leading 128 bytes of the packet. The Identification field additionally prov=

ides

the destination with a means to detect replayed packets. Note that this

provides less authentication assurance than AH, since a middlebox on the

path could alter the "tail" of the packet beyond the leading 128 bytes. But=

,

it defeats off-path spoofing attacks.

 

Note again that, when the source and destination are not engaged in a

digital signing and verification relationship, the source could sign the

message any way it wants, e.g., by writing a constant or time-varying

nonce. In that case, the destination would be vulnerable to an off-path

attacker guessing the nonce and hence should not use the nonce as

a data origin authentication signature.

 

Thanks - Fred

 

PS The number 128 was chosen so that enough of the packet would be

included to provide sufficient inter-packet diversity in calculating the di=

gital

signature. However, I could also see an arguement for a smaller number,

e.g., 64, 80, 96, etc.

 

--Boundary_(ID_fYgWva3uZF/LVrygWdUuoQ)-- From fgont@si6networks.com Fri Jan 13 05:22:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD59C21F8663 for ; Fri, 13 Jan 2012 05:22:35 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNkAGnoz7MYx for ; Fri, 13 Jan 2012 05:22:35 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5C72F21F8578 for ; Fri, 13 Jan 2012 05:22:34 -0800 (PST) Received: from 61-128-17-190.fibertel.com.ar ([190.17.128.61] helo=[192.168.0.120]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rlh5R-0002cs-27; Fri, 13 Jan 2012 14:22:29 +0100 Message-ID: <4F10300E.1040606@si6networks.com> Date: Fri, 13 Jan 2012 10:22:22 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: New revision of draft-gont-6man-flowlabel-security X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 13:22:36 -0000 Folks, I have just posted a revision of the aforementioned I-D. It is available at: Any comments will be appreciated. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-6man-flowlabel-security-02.txt Date: Fri, 13 Jan 2012 05:02:38 -0800 From: internet-drafts@ietf.org To: fernando@gont.com.ar CC: fernando@gont.com.ar A new version of I-D, draft-gont-6man-flowlabel-security-02.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-6man-flowlabel-security Revision: 02 Title: Security Assessment of the IPv6 Flow Label Creation date: 2012-01-12 WG ID: Individual Submission Number of pages: 20 Abstract: This document discusses the security implications of the IPv6 "Flow Label" header field, and analyzes possible schemes for selecting the Flow Label value of IPv6 packets. The IETF Secretariat From Fred.L.Templin@boeing.com Fri Jan 13 09:37:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A82621F86A4 for ; Fri, 13 Jan 2012 09:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnE2Vaq644Ev for ; Fri, 13 Jan 2012 09:37:43 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by ietfa.amsl.com (Postfix) with ESMTP id DF63F21F8698 for ; Fri, 13 Jan 2012 09:37:42 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0DHc65B020060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2012 11:38:08 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q0DHbQnv015315; Fri, 13 Jan 2012 09:37:26 -0800 (PST) Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0DHbN0u015275 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 13 Jan 2012 09:37:25 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Fri, 13 Jan 2012 09:37:24 -0800 From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Date: Fri, 13 Jan 2012 09:37:23 -0800 Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) Thread-Topic: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) Thread-Index: AczRritoWWU5eFohSYun74sigPsbGwAXpFLA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF49BXCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:37:44 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF49BXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sreenatha, You are right that the draft needs to be clarified on this point. The answer is that whether or not there is a shared secret key the destination node can validate or not validate the signature as it deems fit. If the destination willl not validate the signature, then it simply ignores the SEAL option and processes the next option. If the destination sees the SEAL option as an unknown option type, then it should ignore the option and process the next option. This would seem to indicate that the SEAL digital signature should appear as a Destination Option and not as its own header extension, because the destination would discard any packet with an extension header having an unknown "Next Header" value. I will update the draft with these changes. Thanks - Fred ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sre= enatha setty Sent: Thursday, January 12, 2012 8:45 PM To: fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-r= elated Security issues) (Templin, Fred L) Hi Fred, In the draft, the behavior of destination node in processing the SEAL= header is need to be cleared. If nodes are not exchanging symmetric key a= nd it received SEAL extension header packet and the packet is not ICMPv6 er= ror packet, how destination node should process the SEAL header? It should = simply ignore the SEAL header and go to next header processing or it should= try to validate the signature in SEAL header? Thanks - Sreenatha ----------------------------------------------------- From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Cc: "ipv6@ietf.org" Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Sreenatha, Since posting my message, I have submitted an actual draft that deprecates the list-posted pre-draft: https://datatracker.ietf.org/doc/draft-templin-sealopt/ The posted version makes the observation that the source can use the SEAL option either in coordination with the destination (in which case the sourc= e includes a digital signature that the destination can verify) or independen= tly from the destination (in which case the source can include any type of signature it likes). Your question seems to stem from the former case: > 1. SEAL IPv6 extension header functionality is similar to AH header funct= ionality > which is already standardized in RFC 2402(IP Authentication Header). AH h= eader > also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation = for IPv6 > in RFC 2402] which is used to check the integrity of the packet. So what = is the > advantage of using SEAL header over AH header? When the source and destination share a secret key used for digital signatu= re calculation and verification, it is true that SEAL somewhat resembles AH. However, the SEAL source only calculates the digital signature over the lea= ding 128 bytes of the packet beginning with the SEAL header itself. So, unlike A= H, the digital signature does not cover the entire packet and does not cover a pseudo-header of the IPv6 header. This has two important implications. First, when a router on the path needs= to drop an IPv6 packet with a SEAL option and return an ICMP error message, th= e packet-in-error within the ICMP will include enough of the leading portion = of the SEAL packet so that the source can verify that the ICMP was generated by an on-path router. The same is not true for AH, since the AH ICV covers the en= tire packet, and the packet-in-error field within the ICMP message may not inclu= de the entire packet. Second, the digital signature will remain valid even if = the IPv6 header is subject to network address translation. ------------------------------ Message: 3 Message-ID: ight weight data origin authentication and integrity checking capability for the leading 128 bytes of the packet. The Identification field additionally prov= =3D ides the destination with a means to detect replayed packets. Note that this provides less authentication assurance than AH, since a middlebox on the path could alter the "tail" of the packet beyond the leading 128 bytes. But= =3D , it defeats off-path spoofing attacks. Note again that, when the source and destination are not engaged in a digital signing and verification relationship, the source could sign the message any way it wants, e.g., by writing a constant or time-varying nonce. In that case, the destination would be vulnerable to an off-path attacker guessing the nonce and hence should not use the nonce as a data origin authentication signature. Thanks - Fred PS The number 128 was chosen so that enough of the packet would be included to provide sufficient inter-packet diversity in calculating the di= =3D gital signature. However, I could also see an arguement for a smaller number, e.g., 64, 80, 96, etc. --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF49BXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sreenatha,
 
You are right that the draft needs to be clarified= on this=20 point. The
answer is that whether or not there is a shared se= cret key=20 the
destination node can validate or not validate the= =20 signature as it
deems fit. If the destination willl not validate t= he=20 signature, then it
simply ignores the SEAL option and processes=20 the next option.
 
If the destination sees the SEAL option as an unkn= own=20 option
type, then it should ignore the option and process= the=20 next
option. This= would seem=20 to indicate that the SEAL digital signature
should appear as a Destination Option and no= t as=20 its own header
extension, beca= use the=20 destination would discard any packet with
an extension head= er having an=20 unknown "Next Header" value. I
will update the draft with these=20 changes.
 
Thanks - Fred

From: ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org] On Behalf Of Sreenatha=20 setty
Sent: Thursday, January 12, 2012 8:45 PM
To:=20 fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE:Pre-d= raft:=20 SEAL as an IPv6 extension header(was:Fragmentation-related Security issue= s)=20 (Templin, Fred L)

Hi Fred,

      In the draft, th= e=20 behavior of destination node in processing the SEAL header is need to be= =20 cleared.  If nodes a= re not=20 exchanging symmetric key and it received SEAL extension header packet and= the=20 packet is not ICMPv6 error packet, how destination node should process th= e=20 SEAL header? It should simply ignore the SEAL header and go to next heade= r=20 processing or it should try to validate the signature in SEAL=20 header?

 

Thanks - Sreenatha

     =20

-----------------------------------------------= ------

From: "Templin, Fred L"=20 <Fred.L.Templin@boeing.com>

To: Sreenatha setty <sreenatha.b@huawei.com&= gt;,=20 "fltemplin@acm.org"

     =20 <fltemplin@acm.org>

Cc: "ipv6@ietf.org"=20 <ipv6@ietf.org>

Subject: RE: RE:Pre-draft: SEAL as an IPv6 exte= nsion=20 header

     =20 (was:Fragmentation-related Security issues)

Message-ID:

     =20 <E1829B60731D1740BB7A0626B4FAF0A65C793AF16B@XCH-NW-01V.nw.nos.boeing.c= om>

     =20

Content-Type: text/plain;=20 charset=3D"us-ascii"

 

Hi Sreenatha,

 

Since posting my message, I have submitted an a= ctual=20 draft that deprecates

the list-posted=20 pre-draft:

 

https://datatracker.ietf.org/doc/draft-templin-= sealopt/

 

The posted version makes the observation that t= he=20 source can use the SEAL

option either in coordination with the destinat= ion (in=20 which case the source

includes a digital signature that the destinati= on can=20 verify) or independently

from the destination (in which case the source = can=20 include any type of

signature it likes). Your question seems to ste= m from=20 the former case:

 

> 1. SEAL IPv6 extension header functionalit= y is=20 similar to AH header functionality

> which is already standardized in RFC 2402(= IP=20 Authentication Header). AH header

> also calculates the ICV of the packet [Sec= tion=20 3.3.3.1.2 ICV Computation for IPv6

> in RFC 2402] which is used to check the in= tegrity=20 of the packet. So what is the

> advantage of using SEAL header over AH=20 header?

 

When the source and destination share a secret = key=20 used for digital signature

calculation and verification, it is true that S= EAL=20 somewhat resembles AH.

However, the SEAL source only calculates the di= gital=20 signature over the leading

128 bytes of the packet beginning with the SEAL= header=20 itself. So, unlike AH,

the digital signature does not cover the entire= packet=20 and does not cover a

pseudo-header of the IPv6=20 header.

 

This has two important implications. First, whe= n a=20 router on the path needs to

drop an IPv6 packet with a SEAL option and retu= rn an=20 ICMP error message, the

packet-in-error within the ICMP will include en= ough of=20 the leading portion  of the

SEAL packet so that the source can verify that = the=20 ICMP was generated by an

on-path router. The same is not true for AH, si= nce the=20 AH ICV covers the entire

packet, and the packet-in-error field within th= e ICMP=20 message may not include

the entire packet. Second, the digital signatur= e will=20 remain valid even if the IPv6

header is subject to network address=20 translation.

 

------------------------------

 

Message: 3

Message-ID:=20 <mailman.1071.1326393779.3200.ipv6@ietf.org>

 

ight

weight data origin authentication and integrity= =20 checking capability for the

leading 128 bytes of the packet. The Identifica= tion=20 field additionally prov=3D

ides

the destination with a means to detect replayed= =20 packets. Note that this

provides less authentication assurance than AH,= since=20 a middlebox on the

path could alter the "tail" of the packet beyon= d the=20 leading 128 bytes. But=3D

,

it defeats off-path spoofing=20 attacks.

 

Note again that, when the source and destinatio= n are=20 not engaged in a

digital signing and verification relationship, = the=20 source could sign the

message any way it wants, e.g., by writing a co= nstant=20 or time-varying

nonce. In that case, the destination would be=20 vulnerable to an off-path

attacker guessing the nonce and hence should no= t use=20 the nonce as

a data origin authentication=20 signature.

 

Thanks - Fred

 

PS The number 128 was chosen so that enough of = the=20 packet would be

included to provide sufficient inter-packet div= ersity=20 in calculating the di=3D

gital

signature. However, I could also see an argueme= nt for=20 a smaller number,

e.g., 64, 80, 96, etc.=

 

--_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF49BXCHNW01Vnwnos_-- From wwwrun@rfc-editor.org Fri Jan 13 12:08:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398241F0C42 for ; Fri, 13 Jan 2012 12:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBn4znUAI2g7 for ; Fri, 13 Jan 2012 12:08:08 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B027A1F0C40 for ; Fri, 13 Jan 2012 12:08:08 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 18954B1E002; Fri, 13 Jan 2012 12:05:22 -0800 (PST) To: suresh.krishnan@ericsson.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, bob.hinden@gmail.com, brian@innovationslab.net Subject: [Technical Errata Reported] RFC5722 (3089) From: RFC Errata System Message-Id: <20120113200522.18954B1E002@rfc-editor.org> Date: Fri, 13 Jan 2012 12:05:22 -0800 (PST) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:08:09 -0000 The following errata report has been submitted for RFC5722, "Handling of Overlapping IPv6 Fragments". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5722&eid=3089 -------------------------------------- Type: Technical Reported by: Simon Perreault Section: 4 Original Text ------------- IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT create overlapping fragments. When reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments, including those not yet received) MUST be silently discarded. Corrected Text -------------- IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT create overlapping fragments. When reassembling an IPv6 datagram, if one or more its constituent fragments is determined to be an overlapping fragment, the entire datagram (and any constituent fragments) MUST be silently discarded. Notes ----- Discarding fragments "including those not yet received" is not implementable. You'd have to keep state about the (source, destination, protocol, id) 4-tuple for MSL (120 seconds). If you do this you create two bugs: - A new attack vector: an attacker could eat your resources. And if you just limit the number of such state entries then you fail to implement RFC 5722 correctly. - It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update. The proposal is simply to remove the "including those not yet received" bit. Normal host stacks do not keep state once a fragment has been reassembled. You reassemble the full packet and clear the fragment table. So this corrected text would align the RFC with actual practice. This errata report results from an implementation attempt by OpenBSD. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5722 (draft-ietf-6man-overlap-fragment-03) -------------------------------------- Title : Handling of Overlapping IPv6 Fragments Publication Date : December 2009 Author(s) : S. Krishnan Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From simon.perreault@viagenie.ca Fri Jan 13 12:42:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94A421F8666 for ; Fri, 13 Jan 2012 12:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5uezcfvtddm for ; Fri, 13 Jan 2012 12:42:55 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4734421F861A for ; Fri, 13 Jan 2012 12:42:55 -0800 (PST) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 609D220EFE; Fri, 13 Jan 2012 15:42:24 -0500 (EST) Message-ID: <4F10972F.8080306@viagenie.ca> Date: Fri, 13 Jan 2012 15:42:23 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: RFC Errata System Subject: Re: [Technical Errata Reported] RFC5722 (3089) References: <20120113200522.18954B1E002@rfc-editor.org> In-Reply-To: <20120113200522.18954B1E002@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, suresh.krishnan@ericsson.com, rdroms.ietf@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:42:56 -0000 On 2012-01-13 15:05, RFC Errata System wrote: > - It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update. I was confusing IPv6 with IPv4 (they do look similar!). You can ignore this argument. The other argument still stands. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Fred.L.Templin@boeing.com Fri Jan 13 16:10:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249F921F84D2 for ; Fri, 13 Jan 2012 16:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0y5V6sNKVCF for ; Fri, 13 Jan 2012 16:10:26 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietfa.amsl.com (Postfix) with ESMTP id 93AC221F84C3 for ; Fri, 13 Jan 2012 16:10:18 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0E0A7Gk015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jan 2012 16:10:10 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q0E0A6mQ014844; Fri, 13 Jan 2012 16:10:06 -0800 (PST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0E0A3e7014784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 13 Jan 2012 16:10:04 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Fri, 13 Jan 2012 16:10:03 -0800 From: "Templin, Fred L" To: Sreenatha setty , "ipv6@ietf.org" Date: Fri, 13 Jan 2012 16:10:01 -0800 Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) Thread-Topic: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) Thread-Index: AczRritoWWU5eFohSYun74sigPsbGwAXpFLAABD05nA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF6EBXCHNW01Vnwnos_" MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 00:10:35 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF6EBXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, I have posted a new version that addresses these issues: https://datatracker.ietf.org/doc/draft-templin-sealopt/ Thanks - Fred ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tem= plin, Fred L Sent: Friday, January 13, 2012 9:37 AM To: Sreenatha setty; fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentati= on-related Security issues) (Templin, Fred L) Hi Sreenatha, You are right that the draft needs to be clarified on this point. The answer is that whether or not there is a shared secret key the destination node can validate or not validate the signature as it deems fit. If the destination willl not validate the signature, then it simply ignores the SEAL option and processes the next option. If the destination sees the SEAL option as an unknown option type, then it should ignore the option and process the next option. This would seem to indicate that the SEAL digital signature should appear as a Destination Option and not as its own header extension, because the destination would discard any packet with an extension header having an unknown "Next Header" value. I will update the draft with these changes. Thanks - Fred ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sre= enatha setty Sent: Thursday, January 12, 2012 8:45 PM To: fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-r= elated Security issues) (Templin, Fred L) Hi Fred, In the draft, the behavior of destination node in processing the SEAL= header is need to be cleared. If nodes are not exchanging symmetric key a= nd it received SEAL extension header packet and the packet is not ICMPv6 er= ror packet, how destination node should process the SEAL header? It should = simply ignore the SEAL header and go to next header processing or it should= try to validate the signature in SEAL header? Thanks - Sreenatha ----------------------------------------------------- From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Cc: "ipv6@ietf.org" Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Sreenatha, Since posting my message, I have submitted an actual draft that deprecates the list-posted pre-draft: https://datatracker.ietf.org/doc/draft-templin-sealopt/ The posted version makes the observation that the source can use the SEAL option either in coordination with the destination (in which case the sourc= e includes a digital signature that the destination can verify) or independen= tly from the destination (in which case the source can include any type of signature it likes). Your question seems to stem from the former case: > 1. SEAL IPv6 extension header functionality is similar to AH header funct= ionality > which is already standardized in RFC 2402(IP Authentication Header). AH h= eader > also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation = for IPv6 > in RFC 2402] which is used to check the integrity of the packet. So what = is the > advantage of using SEAL header over AH header? When the source and destination share a secret key used for digital signatu= re calculation and verification, it is true that SEAL somewhat resembles AH. However, the SEAL source only calculates the digital signature over the lea= ding 128 bytes of the packet beginning with the SEAL header itself. So, unlike A= H, the digital signature does not cover the entire packet and does not cover a pseudo-header of the IPv6 header. This has two important implications. First, when a router on the path needs= to drop an IPv6 packet with a SEAL option and return an ICMP error message, th= e packet-in-error within the ICMP will include enough of the leading portion = of the SEAL packet so that the source can verify that the ICMP was generated by an on-path router. The same is not true for AH, since the AH ICV covers the en= tire packet, and the packet-in-error field within the ICMP message may not inclu= de the entire packet. Second, the digital signature will remain valid even if = the IPv6 header is subject to network address translation. ------------------------------ Message: 3 Message-ID: ight weight data origin authentication and integrity checking capability for the leading 128 bytes of the packet. The Identification field additionally prov= =3D ides the destination with a means to detect replayed packets. Note that this provides less authentication assurance than AH, since a middlebox on the path could alter the "tail" of the packet beyond the leading 128 bytes. But= =3D , it defeats off-path spoofing attacks. Note again that, when the source and destination are not engaged in a digital signing and verification relationship, the source could sign the message any way it wants, e.g., by writing a constant or time-varying nonce. In that case, the destination would be vulnerable to an off-path attacker guessing the nonce and hence should not use the nonce as a data origin authentication signature. Thanks - Fred PS The number 128 was chosen so that enough of the packet would be included to provide sufficient inter-packet diversity in calculating the di= =3D gital signature. However, I could also see an arguement for a smaller number, e.g., 64, 80, 96, etc. --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF6EBXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI, I have posted a new version that addresses th= ese=20 issues:
 
https://da= tatracker.ietf.org/doc/draft-templin-sealopt/
 
Thanks - Fred

From: ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred=20 L
Sent: Friday, January 13, 2012 9:37 AM
To: Sreenath= a=20 setty; fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: R= E:=20 RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related= =20 Security issues) (Templin, Fred L)

Hi Sreenatha,
 
You are right that the draft needs to be clarifi= ed on=20 this point. The
answer is that whether or not there is a shared = secret=20 key the
destination node can validate or not validate th= e=20 signature as it
deems fit. If the destination willl not validate= the=20 signature, then it
simply ignores the SEAL option and processes=20 the next option.
 
If the destination sees the SEAL option as an un= known=20 option
type, then it should ignore the option and proce= ss the=20 next
option. Th= is would seem=20 to indicate that the SEAL digital signature
should appear as a Destination Option and = not as=20 its own header
extension, be= cause the=20 destination would discard any packet with
an extension he= ader having=20 an unknown "Next Header" value. I
will update the draft with these=20 changes.
 
Thanks - Fred

From: ipv6-bounces@ietf.org=20 [mailto:ipv6-bounces@ietf.org] On Behalf Of Sreenatha=20 setty
Sent: Thursday, January 12, 2012 8:45 PM
To:= =20 fltemplin@acm.org
Cc: ipv6@ietf.org
Subject:=20 RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-relate= d=20 Security issues) (Templin, Fred L)

Hi Fred,

      In the draft, = the=20 behavior of destination node in processing the SEAL header is need to b= e=20 cleared.  If nodes= are=20 not exchanging symmetric key and it received SEAL extension header pack= et=20 and the packet is not ICMPv6 error packet, how destination node should= =20 process the SEAL header? It should simply ignore the SEAL header and go= to=20 next header processing or it should try to validate the signature in SE= AL=20 header?

 

Thanks - Sreenatha

     =20

---------------------------------------------= --------

From: "Templin, Fred L"=20 <Fred.L.Templin@boeing.com>

To: Sreenatha setty <sreenatha.b@huawei.co= m>,=20 "fltemplin@acm.org"

     =20 <fltemplin@acm.org>

Cc: "ipv6@ietf.org"=20 <ipv6@ietf.org>

Subject: RE: RE:Pre-draft: SEAL as an IPv6 ex= tension=20 header

     =20 (was:Fragmentation-related Security issues)

Message-ID:

     =20 <E1829B60731D1740BB7A0626B4FAF0A65C793AF16B@XCH-NW-01V.nw.nos.boeing= .com>

     =20

Content-Type: text/plain;=20 charset=3D"us-ascii"

 

Hi Sreenatha,

 

Since posting my message, I have submitted an= actual=20 draft that deprecates

the list-posted=20 pre-draft:

 

https://datatracker.ietf.org/doc/draft-templi= n-sealopt/

 

The posted version makes the observation that= the=20 source can use the SEAL

option either in coordination with the destin= ation=20 (in which case the source

includes a digital signature that the destina= tion=20 can verify) or independently

from the destination (in which case the sourc= e can=20 include any type of

signature it likes). Your question seems to s= tem=20 from the former case:

 

> 1. SEAL IPv6 extension header functional= ity is=20 similar to AH header functionality

> which is already standardized in RFC 240= 2(IP=20 Authentication Header). AH header

> also calculates the ICV of the packet [S= ection=20 3.3.3.1.2 ICV Computation for IPv6

> in RFC 2402] which is used to check the= =20 integrity of the packet. So what is the

> advantage of using SEAL header over AH=20 header?

 

When the source and destination share a secre= t key=20 used for digital signature

calculation and verification, it is true that= SEAL=20 somewhat resembles AH.

However, the SEAL source only calculates the = digital=20 signature over the leading

128 bytes of the packet beginning with the SE= AL=20 header itself. So, unlike AH,

the digital signature does not cover the enti= re=20 packet and does not cover a

pseudo-header of the IPv6=20 header.

 

This has two important implications. First, w= hen a=20 router on the path needs to

drop an IPv6 packet with a SEAL option and re= turn an=20 ICMP error message, the

packet-in-error within the ICMP will include = enough=20 of the leading portion  of the

SEAL packet so that the source can verify tha= t the=20 ICMP was generated by an

on-path router. The same is not true for AH, = since=20 the AH ICV covers the entire

packet, and the packet-in-error field within = the=20 ICMP message may not include

the entire packet. Second, the digital signat= ure=20 will remain valid even if the IPv6

header is subject to network address=20 translation.

 

------------------------------

 

Message: 3

Message-ID:=20 <mailman.1071.1326393779.3200.ipv6@ietf.org>

 

ight

weight data origin authentication and integri= ty=20 checking capability for the

leading 128 bytes of the packet. The Identifi= cation=20 field additionally prov=3D

ides

the destination with a means to detect replay= ed=20 packets. Note that this

provides less authentication assurance than A= H,=20 since a middlebox on the

path could alter the "tail" of the packet bey= ond the=20 leading 128 bytes. But=3D

,

it defeats off-path spoofing=20 attacks.

 

Note again that, when the source and destinat= ion are=20 not engaged in a

digital signing and verification relationship= , the=20 source could sign the

message any way it wants, e.g., by writing a= =20 constant or time-varying

nonce. In that case, the destination would be= =20 vulnerable to an off-path

attacker guessing the nonce and hence should = not use=20 the nonce as

a data origin authentication=20 signature.

 

Thanks - Fred

 

PS The number 128 was chosen so that enough o= f the=20 packet would be

included to provide sufficient inter-packet=20 diversity in calculating the di=3D

gital

signature. However, I could also see an argue= ment=20 for a smaller number,

e.g., 64, 80, 96, etc.

 <= /FONT>

--_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF6EBXCHNW01Vnwnos_-- From fgont@si6networks.com Sat Jan 14 14:51:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A23421F84E2 for ; Sat, 14 Jan 2012 14:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kR15wijNRTWq for ; Sat, 14 Jan 2012 14:51:31 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 200AA21F84DF for ; Sat, 14 Jan 2012 14:51:30 -0800 (PST) Received: from [190.50.164.7] (helo=[192.168.1.37]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RmCRL-0001LB-2h; Sat, 14 Jan 2012 23:51:13 +0100 Message-ID: <4F1183A2.90302@si6networks.com> Date: Sat, 14 Jan 2012 10:31:14 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: RFC Errata System Subject: Re: [Technical Errata Reported] RFC5722 (3089) References: <20120113200522.18954B1E002@rfc-editor.org> In-Reply-To: <20120113200522.18954B1E002@rfc-editor.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, suresh.krishnan@ericsson.com, rdroms.ietf@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 22:51:31 -0000 On 01/13/2012 05:05 PM, RFC Errata System wrote: > Notes ----- Discarding fragments "including those not yet received" > is not implementable. You'd have to keep state about the (source, > destination, protocol, id) 4-tuple for MSL (120 seconds). If you do > this you create two bugs: - A new attack vector: an attacker could > eat your resources. And if you just limit the number of such state > entries then you fail to implement RFC 5722 correctly. [...] > > The proposal is simply to remove the "including those not yet > received" bit. Normal host stacks do not keep state once a fragment > has been reassembled. You reassemble the full packet and clear the > fragment table. So this corrected text would align the RFC with > actual practice. > > This errata report results from an implementation attempt by > OpenBSD. FWIW, this follows the general principle that "you don't add more state for malicious traffic". That aside, at least not spending too much time on it I couldn't come up with a scenario in which "not dropping future fragments" would enable the attack discussed in the aforementioned RFC. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gorry@erg.abdn.ac.uk Mon Jan 16 00:10:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B91521F84E6 for ; Mon, 16 Jan 2012 00:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1gLVgTEFFex for ; Mon, 16 Jan 2012 00:10:20 -0800 (PST) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id 4A78221F84DF for ; Mon, 16 Jan 2012 00:10:18 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q0G8A7KT014937; Mon, 16 Jan 2012 08:10:09 GMT Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Mon, 16 Jan 2012 08:15:11 -0000 Message-ID: <574673097a656d6d83039153c84f968f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <20120113200522.18954B1E002@rfc-editor.org> References: <20120113200522.18954B1E002@rfc-editor.org> Date: Mon, 16 Jan 2012 08:15:11 -0000 Subject: Re: [Technical Errata Reported] RFC5722 (3089) From: gorry@erg.abdn.ac.uk To: "RFC Errata System" User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Cc: brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, suresh.krishnan@ericsson.com, rdroms.ietf@gmail.com, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 08:10:21 -0000 I noticed this Errata. I'm OK with removing the requirement (MUST), but I think the recommendation is not entirely bad to discard fragments that may follow - albeit for a limited time and subject to finding a way to implement. MSL As presently defined could also be regarded as too harsh, that's a different topic. The note mentions "normal" stacks: Normal stacks do not keep state when the IP packet has been resembled (forwarded), but do keep it while the IP packet is not complete. Hence, if the packet did not reassemble, the "overlap" state would be kept. Gorry > > The following errata report has been submitted for RFC5722, > "Handling of Overlapping IPv6 Fragments". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5722&eid=3089 > > -------------------------------------- > Type: Technical > Reported by: Simon Perreault > > Section: 4 > > Original Text > ------------- > IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT > create overlapping fragments. When reassembling an IPv6 datagram, if > one or more its constituent fragments is determined to be an > overlapping fragment, the entire datagram (and any constituent > fragments, including those not yet received) MUST be silently > discarded. > > Corrected Text > -------------- > IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT > create overlapping fragments. When reassembling an IPv6 datagram, if > one or more its constituent fragments is determined to be an > overlapping fragment, the entire datagram (and any constituent > fragments) MUST be silently discarded. > > Notes > ----- > Discarding fragments "including those not yet received" is not > implementable. You'd have to keep state about the (source, destination, > protocol, id) 4-tuple for MSL (120 seconds). If you do this you create two > bugs: > - A new attack vector: an attacker could eat your resources. And if you > just limit the number of such state entries then you fail to implement RFC > 5722 correctly. > - It breaks at fairly low speeds. See draft-ietf-intarea-ipv4-id-update. > > The proposal is simply to remove the "including those not yet received" > bit. Normal host stacks do not keep state once a fragment has been > reassembled. You reassemble the full packet and clear the fragment table. > So this corrected text would align the RFC with actual practice. > > This errata report results from an implementation attempt by OpenBSD. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5722 (draft-ietf-6man-overlap-fragment-03) > -------------------------------------- > Title : Handling of Overlapping IPv6 Fragments > Publication Date : December 2009 > Author(s) : S. Krishnan > Category : PROPOSED STANDARD > Source : IPv6 Maintenance > Area : Internet > Stream : IETF > Verifying Party : IESG > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From fernando.gont.netbook.win@gmail.com Mon Jan 16 02:17:20 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAB821F8564 for ; Mon, 16 Jan 2012 02:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jA496EvkgPCo for ; Mon, 16 Jan 2012 02:17:19 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9307221F845D for ; Mon, 16 Jan 2012 02:17:19 -0800 (PST) Received: by yhnn12 with SMTP id n12so551497yhn.31 for ; Mon, 16 Jan 2012 02:17:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=C2l9jqi1l92UOoWOxI63OM1JwTOp9vJZikvxHJuWMCg=; b=iC6R+GuMRtHyrOLB6IOS8tqLVaUFcbaOv3VrugC4MLBdxaiGVviwTWhdLvmNz32pFw bywkkPd0XunNoZ+90EmLBICQJZVug26wRuzQzmDlE7HP/8tT3A+4IDb1ITI9Autye1td R2+g7E+rAfV7F9GYrbEubcKyPBlKlu8GlPFew= Received: by 10.236.76.201 with SMTP id b49mr15625963yhe.11.1326709039217; Mon, 16 Jan 2012 02:17:19 -0800 (PST) Received: from [10.42.43.100] ([190.48.207.118]) by mx.google.com with ESMTPS id i6sm48870730and.3.2012.01.16.02.17.14 (version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 02:17:17 -0800 (PST) Sender: Fernando Gont Message-ID: <4F13F928.5030408@gont.com.ar> Date: Mon, 16 Jan 2012 07:17:12 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk Subject: Re: [Technical Errata Reported] RFC5722 (3089) References: <20120113200522.18954B1E002@rfc-editor.org> <574673097a656d6d83039153c84f968f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <574673097a656d6d83039153c84f968f.squirrel@www.erg.abdn.ac.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: brian@innovationslab.net, ipv6@ietf.org, bob.hinden@gmail.com, suresh.krishnan@ericsson.com, rdroms.ietf@gmail.com, RFC Errata System X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 10:17:20 -0000 Hi, Gorry, On 01/16/2012 05:15 AM, gorry@erg.abdn.ac.uk wrote: > I'm OK with removing the requirement (MUST), but I think the > recommendation is not entirely bad to discard fragments that may follow - > albeit for a limited time and subject to finding a way to implement. It's not that it's "bad". It's that if it is assumed that overlapping fragment are malicious traffic (i.e., it cannot originate from legitimate sources), then there's not much motivoation to do more work (e.g., first prun the fragments, then the "state") or tie system resources (such as those needed to keep state for "future fragments" of that packet). Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From sreenatha.b@huawei.com Mon Jan 16 03:51:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616EA21F8582 for ; Mon, 16 Jan 2012 03:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.383 X-Spam-Level: X-Spam-Status: No, score=-6.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhCxLgMiZmoh for ; Mon, 16 Jan 2012 03:51:21 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 68BB321F8581 for ; Mon, 16 Jan 2012 03:51:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00K5F3LJUH@szxga05-in.huawei.com> for ipv6@ietf.org; Mon, 16 Jan 2012 19:51:19 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXW00ISE3LJHO@szxga05-in.huawei.com> for ipv6@ietf.org; Mon, 16 Jan 2012 19:51:19 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGL58956; Mon, 16 Jan 2012 19:51:01 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Jan 2012 19:50:57 +0800 Received: from blrnshtipl6nc (10.18.1.36) by szxeml416-hub.china.huawei.com (10.82.67.155) with Microsoft SMTP Server id 14.1.323.3; Mon, 16 Jan 2012 19:50:48 +0800 Date: Mon, 16 Jan 2012 17:20:43 +0530 From: Sreenatha setty Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L) In-reply-to: X-Originating-IP: [10.18.1.36] To: "'Templin, Fred L'" Message-id: <8F4DB39B04694D3FB200A2F934DF564D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4841 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_N1o1336Fe/h/W4o0UkSptA)" Thread-index: AczRritoWWU5eFohSYun74sigPsbGwAXpFLAABD05nAAfLHN4A== X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 16 Jan 2012 06:07:28 -0800 Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 11:51:23 -0000 --Boundary_(ID_N1o1336Fe/h/W4o0UkSptA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Fred, Since SEAL Extension header is need to be processed only by destination node, why it should not be treated as NEW DESTINATION OPTION OF TYPE SEAL rather than NEW EXTENSTION HEADER? I went through the new draft proposed by S. Krishnan and other members by name "An uniform format for IPv6 extension headers". Thins drafts specify that any new extension header proposal should explain the facts why it can not be treated as Option's in any of the Existing Extension header and detailed explanation should be given to clarify why it must be treated as Extension Header? Thanks - Sreenatha _____ From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Saturday, January 14, 2012 5:40 AM To: Sreenatha setty; ipv6@ietf.org Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L) FYI, I have posted a new version that addresses these issues: https://datatracker.ietf.org/doc/draft-templin-sealopt/ Thanks - Fred _____ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L Sent: Friday, January 13, 2012 9:37 AM To: Sreenatha setty; fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) Hi Sreenatha, You are right that the draft needs to be clarified on this point. The answer is that whether or not there is a shared secret key the destination node can validate or not validate the signature as it deems fit. If the destination willl not validate the signature, then it simply ignores the SEAL option and processes the next option. If the destination sees the SEAL option as an unknown option type, then it should ignore the option and process the next option. This would seem to indicate that the SEAL digital signature should appear as a Destination Option and not as its own header extension, because the destination would discard any packet with an extension header having an unknown "Next Header" value. I will update the draft with these changes. Thanks - Fred _____ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sreenatha setty Sent: Thursday, January 12, 2012 8:45 PM To: fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L) Hi Fred, In the draft, the behavior of destination node in processing the SEAL header is need to be cleared. If nodes are not exchanging symmetric key and it received SEAL extension header packet and the packet is not ICMPv6 error packet, how destination node should process the SEAL header? It should simply ignore the SEAL header and go to next header processing or it should try to validate the signature in SEAL header? Thanks - Sreenatha ----------------------------------------------------- From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Cc: "ipv6@ietf.org" Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset="us-ascii" Hi Sreenatha, Since posting my message, I have submitted an actual draft that deprecates the list-posted pre-draft: https://datatracker.ietf.org/doc/draft-templin-sealopt/ The posted version makes the observation that the source can use the SEAL option either in coordination with the destination (in which case the source includes a digital signature that the destination can verify) or independently from the destination (in which case the source can include any type of signature it likes). Your question seems to stem from the former case: > 1. SEAL IPv6 extension header functionality is similar to AH header functionality > which is already standardized in RFC 2402(IP Authentication Header). AH header > also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6 > in RFC 2402] which is used to check the integrity of the packet. So what is the > advantage of using SEAL header over AH header? When the source and destination share a secret key used for digital signature calculation and verification, it is true that SEAL somewhat resembles AH. However, the SEAL source only calculates the digital signature over the leading 128 bytes of the packet beginning with the SEAL header itself. So, unlike AH, the digital signature does not cover the entire packet and does not cover a pseudo-header of the IPv6 header. This has two important implications. First, when a router on the path needs to drop an IPv6 packet with a SEAL option and return an ICMP error message, the packet-in-error within the ICMP will include enough of the leading portion of the SEAL packet so that the source can verify that the ICMP was generated by an on-path router. The same is not true for AH, since the AH ICV covers the entire packet, and the packet-in-error field within the ICMP message may not include the entire packet. Second, the digital signature will remain valid even if the IPv6 header is subject to network address translation. ------------------------------ Message: 3 Message-ID: ight weight data origin authentication and integrity checking capability for the leading 128 bytes of the packet. The Identification field additionally prov= ides the destination with a means to detect replayed packets. Note that this provides less authentication assurance than AH, since a middlebox on the path could alter the "tail" of the packet beyond the leading 128 bytes. But= , it defeats off-path spoofing attacks. Note again that, when the source and destination are not engaged in a digital signing and verification relationship, the source could sign the message any way it wants, e.g., by writing a constant or time-varying nonce. In that case, the destination would be vulnerable to an off-path attacker guessing the nonce and hence should not use the nonce as a data origin authentication signature. Thanks - Fred PS The number 128 was chosen so that enough of the packet would be included to provide sufficient inter-packet diversity in calculating the di= gital signature. However, I could also see an arguement for a smaller number, e.g., 64, 80, 96, etc. --Boundary_(ID_N1o1336Fe/h/W4o0UkSptA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Fred,

    Since SEAL Extension header is need to be processed only by destination node, why it should not be treated as NEW DESTINATION OPTION OF TYPE SEAL rather than NEW EXTENSTION HEADER?  I went through the new draft proposed by S. Krishnan and other members by name "An uniform format for IPv6 extension headers". Thins drafts specify that any new extension header proposal should explain the facts why it can not be treated as Option's in any of the Existing Extension header and detailed explanation should be given to clarify why it must be treated as Extension Header?

  
Thanks - Sreenatha

 

 

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Saturday, January 14, 2012 5:40 AM
To: Sreenatha setty; ipv6@ietf.org
Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L)

 

FYI, I have posted a new version that addresses these issues:

 

https://datatracker.ietf.org/doc/draft-templin-sealopt/

 

Thanks - Fred

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Friday, January 13, 2012 9:37 AM
To: Sreenatha setty; fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L)

Hi Sreenatha,

 

You are right that the draft needs to be clarified on this point. The

answer is that whether or not there is a shared secret key the

destination node can validate or not validate the signature as it

deems fit. If the destination willl not validate the signature, then it

simply ignores the SEAL option and processes the next option.

 

If the destination sees the SEAL option as an unknown option

type, then it should ignore the option and process the next

option. This would seem to indicate that the SEAL digital signature

should appear as a Destination Option and not as its own header

extension, because the destination would discard any packet with

an extension header having an unknown "Next Header" value. I

will update the draft with these changes.

 

Thanks - Fred

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sreenatha setty
Sent: Thursday, January 12, 2012 8:45 PM
To: fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-related Security issues) (Templin, Fred L)

Hi Fred,

      In the draft, the behavior of destination node in processing the SEAL header is need to be cleared.  If nodes are not exchanging symmetric key and it received SEAL extension header packet and the packet is not ICMPv6 error packet, how destination node should process the SEAL header? It should simply ignore the SEAL header and go to next header processing or it should try to validate the signature in SEAL header?

 

Thanks - Sreenatha

     

-----------------------------------------------------

From: "Templin, Fred L" <Fred.L.Templin@boeing.com>

To: Sreenatha setty <sreenatha.b@huawei.com>, "fltemplin@acm.org"

      <fltemplin@acm.org>

Cc: "ipv6@ietf.org" <ipv6@ietf.org>

Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header

      (was:Fragmentation-related Security issues)

Message-ID:

      <E1829B60731D1740BB7A0626B4FAF0A65C793AF16B@XCH-NW-01V.nw.nos.boeing.com>

     

Content-Type: text/plain; charset="us-ascii"

 

Hi Sreenatha,

 

Since posting my message, I have submitted an actual draft that deprecates

the list-posted pre-draft:

 

https://datatracker.ietf.org/doc/draft-templin-sealopt/

 

The posted version makes the observation that the source can use the SEAL

option either in coordination with the destination (in which case the source

includes a digital signature that the destination can verify) or independently

from the destination (in which case the source can include any type of

signature it likes). Your question seems to stem from the former case:

 

> 1. SEAL IPv6 extension header functionality is similar to AH header functionality

> which is already standardized in RFC 2402(IP Authentication Header). AH header

> also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation for IPv6

> in RFC 2402] which is used to check the integrity of the packet. So what is the

> advantage of using SEAL header over AH header?

 

When the source and destination share a secret key used for digital signature

calculation and verification, it is true that SEAL somewhat resembles AH.

However, the SEAL source only calculates the digital signature over the leading

128 bytes of the packet beginning with the SEAL header itself. So, unlike AH,

the digital signature does not cover the entire packet and does not cover a

pseudo-header of the IPv6 header.

 

This has two important implications. First, when a router on the path needs to

drop an IPv6 packet with a SEAL option and return an ICMP error message, the

packet-in-error within the ICMP will include enough of the leading portion  of the

SEAL packet so that the source can verify that the ICMP was generated by an

on-path router. The same is not true for AH, since the AH ICV covers the entire

packet, and the packet-in-error field within the ICMP message may not include

the entire packet. Second, the digital signature will remain valid even if the IPv6

header is subject to network address translation.

 

------------------------------

 

Message: 3

Message-ID: <mailman.1071.1326393779.3200.ipv6@ietf.org>

 

ight

weight data origin authentication and integrity checking capability for the

leading 128 bytes of the packet. The Identification field additionally prov=

ides

the destination with a means to detect replayed packets. Note that this

provides less authentication assurance than AH, since a middlebox on the

path could alter the "tail" of the packet beyond the leading 128 bytes. But=

,

it defeats off-path spoofing attacks.

 

Note again that, when the source and destination are not engaged in a

digital signing and verification relationship, the source could sign the

message any way it wants, e.g., by writing a constant or time-varying

nonce. In that case, the destination would be vulnerable to an off-path

attacker guessing the nonce and hence should not use the nonce as

a data origin authentication signature.

 

Thanks - Fred

 

PS The number 128 was chosen so that enough of the packet would be

included to provide sufficient inter-packet diversity in calculating the di=

gital

signature. However, I could also see an arguement for a smaller number,

e.g., 64, 80, 96, etc.

 

--Boundary_(ID_N1o1336Fe/h/W4o0UkSptA)-- From Fred.L.Templin@boeing.com Mon Jan 16 07:30:12 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF021F861E for ; Mon, 16 Jan 2012 07:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+2-1QpPbNnE for ; Mon, 16 Jan 2012 07:30:10 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id ADADD21F860F for ; Mon, 16 Jan 2012 07:30:10 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0GFTra0013965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jan 2012 07:29:56 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q0GFU4Kq029534; Mon, 16 Jan 2012 09:30:04 -0600 (CST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0GFU1SR029488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 16 Jan 2012 09:30:02 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Mon, 16 Jan 2012 07:29:49 -0800 From: "Templin, Fred L" To: Sreenatha setty Date: Mon, 16 Jan 2012 07:29:46 -0800 Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L) Thread-Topic: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred L) Thread-Index: AczRritoWWU5eFohSYun74sigPsbGwAXpFLAABD05nAAfLHN4AAH6HZQ Message-ID: References: <8F4DB39B04694D3FB200A2F934DF564D@china.huawei.com> In-Reply-To: <8F4DB39B04694D3FB200A2F934DF564D@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7BDXCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:30:12 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7BDXCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sreenatha, In the -01 draft, it is indeed proposing that the SEAL field be formatted a= s a new destination option of type SEAL and not a new extension header. Here is the revised abstract: "The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 destination option that contains a digital signature inserted by the source. The source can thereafter use the signature to verify that any ICMPv6 messages received actually came from a router on the path, while destinations that share a secret key with the source can verify the signature to ensure data origin authentication." Thanks - Fred ________________________________ From: Sreenatha setty [mailto:sreenatha.b@huawei.com] Sent: Monday, January 16, 2012 3:51 AM To: Templin, Fred L Cc: ipv6@ietf.org Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentatio= n-related Security issues) (Templin, Fred L) Hi Fred, Since SEAL Extension header is need to be processed only by destination= node, why it should not be treated as NEW DESTINATION OPTION OF TYPE SEAL = rather than NEW EXTENSTION HEADER? I went through the new draft proposed b= y S. Krishnan and other members by name "An uniform format for IPv6 extensi= on headers". Thins drafts specify that any new extension header proposal sh= ould explain the facts why it can not be treated as Option's in any of the = Existing Extension header and detailed explanation should be given to clari= fy why it must be treated as Extension Header? Thanks - Sreenatha ________________________________ From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] Sent: Saturday, January 14, 2012 5:40 AM To: Sreenatha setty; ipv6@ietf.org Subject: RE: RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentatio= n-related Security issues) (Templin, Fred L) FYI, I have posted a new version that addresses these issues: https://datatracker.ietf.org/doc/draft-templin-sealopt/ Thanks - Fred ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Tem= plin, Fred L Sent: Friday, January 13, 2012 9:37 AM To: Sreenatha setty; fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentati= on-related Security issues) (Templin, Fred L) Hi Sreenatha, You are right that the draft needs to be clarified on this point. The answer is that whether or not there is a shared secret key the destination node can validate or not validate the signature as it deems fit. If the destination willl not validate the signature, then it simply ignores the SEAL option and processes the next option. If the destination sees the SEAL option as an unknown option type, then it should ignore the option and process the next option. This would seem to indicate that the SEAL digital signature should appear as a Destination Option and not as its own header extension, because the destination would discard any packet with an extension header having an unknown "Next Header" value. I will update the draft with these changes. Thanks - Fred ________________________________ From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sre= enatha setty Sent: Thursday, January 12, 2012 8:45 PM To: fltemplin@acm.org Cc: ipv6@ietf.org Subject: RE:Pre-draft: SEAL as an IPv6 extension header(was:Fragmentation-r= elated Security issues) (Templin, Fred L) Hi Fred, In the draft, the behavior of destination node in processing the SEAL= header is need to be cleared. If nodes are not exchanging symmetric key a= nd it received SEAL extension header packet and the packet is not ICMPv6 er= ror packet, how destination node should process the SEAL header? It should = simply ignore the SEAL header and go to next header processing or it should= try to validate the signature in SEAL header? Thanks - Sreenatha ----------------------------------------------------- From: "Templin, Fred L" To: Sreenatha setty , "fltemplin@acm.org" Cc: "ipv6@ietf.org" Subject: RE: RE:Pre-draft: SEAL as an IPv6 extension header (was:Fragmentation-related Security issues) Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Hi Sreenatha, Since posting my message, I have submitted an actual draft that deprecates the list-posted pre-draft: https://datatracker.ietf.org/doc/draft-templin-sealopt/ The posted version makes the observation that the source can use the SEAL option either in coordination with the destination (in which case the sourc= e includes a digital signature that the destination can verify) or independen= tly from the destination (in which case the source can include any type of signature it likes). Your question seems to stem from the former case: > 1. SEAL IPv6 extension header functionality is similar to AH header funct= ionality > which is already standardized in RFC 2402(IP Authentication Header). AH h= eader > also calculates the ICV of the packet [Section 3.3.3.1.2 ICV Computation = for IPv6 > in RFC 2402] which is used to check the integrity of the packet. So what = is the > advantage of using SEAL header over AH header? When the source and destination share a secret key used for digital signatu= re calculation and verification, it is true that SEAL somewhat resembles AH. However, the SEAL source only calculates the digital signature over the lea= ding 128 bytes of the packet beginning with the SEAL header itself. So, unlike A= H, the digital signature does not cover the entire packet and does not cover a pseudo-header of the IPv6 header. This has two important implications. First, when a router on the path needs= to drop an IPv6 packet with a SEAL option and return an ICMP error message, th= e packet-in-error within the ICMP will include enough of the leading portion = of the SEAL packet so that the source can verify that the ICMP was generated by an on-path router. The same is not true for AH, since the AH ICV covers the en= tire packet, and the packet-in-error field within the ICMP message may not inclu= de the entire packet. Second, the digital signature will remain valid even if = the IPv6 header is subject to network address translation. ------------------------------ Message: 3 Message-ID: ight weight data origin authentication and integrity checking capability for the leading 128 bytes of the packet. The Identification field additionally prov= =3D ides the destination with a means to detect replayed packets. Note that this provides less authentication assurance than AH, since a middlebox on the path could alter the "tail" of the packet beyond the leading 128 bytes. But= =3D , it defeats off-path spoofing attacks. Note again that, when the source and destination are not engaged in a digital signing and verification relationship, the source could sign the message any way it wants, e.g., by writing a constant or time-varying nonce. In that case, the destination would be vulnerable to an off-path attacker guessing the nonce and hence should not use the nonce as a data origin authentication signature. Thanks - Fred PS The number 128 was chosen so that enough of the packet would be included to provide sufficient inter-packet diversity in calculating the di= =3D gital signature. However, I could also see an arguement for a smaller number, e.g., 64, 80, 96, etc. --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7BDXCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sreenatha,
 
In the -01 draft, it is indeed proposing that the = SEAL=20 field be formatted as
a <= FONT=20 face=3DArial color=3D#0000ff size=3D2>new destination option of type SEAL a= nd not a=20 new extension header.
Here is the revised abstract:
 
  "The Su= bnetwork=20 Encapsulation and Adaptation Layer (SEAL) provides a
   mid-la= yer=20 header designed for the encapsulation of an inner network
   l= ayer=20 packet within outer network layer headers.  SEAL also=20 supports
   a transport mode of operation, where the inner pay= load=20 corresponds to
   an ordinary transport layer payload. =20 However, SEAL can also provide
   benefit when used as an IPv6= =20 destination option that contains a
   digital signature insert= ed by=20 the source.  The source can thereafter
   use the signatu= re to=20 verify that any ICMPv6 messages received
   actually came from= a=20 router on the path, while destinations that
   share a secret = key=20 with the source can verify the signature to ensure
   data ori= gin=20 authentication."
 
Thanks=20 - Fred
 

From: Sreenatha setty=20 [mailto:sreenatha.b@huawei.com]
Sent: Monday, January 16, 2012= 3:51=20 AM
To: Templin, Fred L
Cc:=20 ipv6@ietf.org
Subject: RE: RE:Pre-draft: SEAL as an IPv6=20 extensionheader(was:Fragmentation-related Security issues) (Templin, Fred= =20 L)

Hi=20 Fred,

    = Since=20 SEAL Extension header is need to be processed only by destination node, w= hy it=20 should not be treated as NEW DESTINATION OPTION OF TYPE SEAL rather than = NEW=20 EXTENSTION HEADER?  I went through the new draft proposed by S. Kris= hnan=20 and other members by name "An uniform format for IPv6 extension headers".= =20 Thins drafts specify that any new extension header proposal should explai= n the=20 facts why it can not be treated as Option's in any of the Existing Extens= ion=20 header and detailed explanation should be given to clarify why it must be= =20 treated as Extension Header?

  
Thanks - Sreenatha

 

 

From:=20 Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Saturday, January 14, 2012 5= :40=20 AM
To: Sreenatha setty= ;=20 ipv6@ietf.org
Subject:= RE:=20 RE:Pre-draft: SEAL as an IPv6 extensionheader(was:Fragmentation-related=20 Security issues) (Templin, Fred L)

 

FYI, I have po= sted a=20 new version that addresses these issues:

 

https://= datatracker.ietf.org/doc/draft-templin-sealopt/

 

Thanks -=20 Fred

 

From:= =20 ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin, Fred=20 L
Sent: Friday, Janu= ary 13,=20 2012 9:37 AM
To: Sre= enatha=20 setty; fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE: RE:Pre-draft: SEAL = as an=20 IPv6 extension header(was:Fragmentation-related Security issues) (Templ= in,=20 Fred L)

Hi=20 Sreenatha,

 

You are righ= t that=20 the draft needs to be clarified on this point.=20 The

answer is th= at=20 whether or not there is a shared secret key the

destination = node=20 can validate or not validate the signature as=20 it

deems fit. I= f the=20 destination willl not validate the signature, then=20 it

simply ignor= es the=20 SEAL option and processes the next option.

 

If the desti= nation=20 sees the SEAL option as an unknown option

type, then i= t=20 should ignore the option and process the next<= /P>

option. This= would=20 seem to indicate that the SEAL digital=20 signature

should appea= r as a=20 Destination Option and not as its own header

extension, b= ecause=20 the destination would discard any packet with<= /P>

an extension= header=20 having an unknown "Next Header" value. I

will update = the=20 draft with these changes.

 

Thanks -=20 Fred

 

Fro= m:=20 ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Sreenatha=20 setty
Sent: Thursd= ay,=20 January 12, 2012 8:45 PM
To: fltemplin@acm.org
Cc: ipv6@ietf.org
Subject: RE:Pre-draft: SEAL as= an=20 IPv6 extension header(was:Fragmentation-related Security issues) (Tem= plin,=20 Fred L)

Hi Fred,

      In the draft= , the=20 behavior of destination node in processing the SEAL header is need to= be=20 cleared.  If nod= es are=20 not exchanging symmetric key and it received SEAL extension header pa= cket=20 and the packet is not ICMPv6 error packet, how destination node shoul= d=20 process the SEAL header? It should simply ignore the SEAL header and = go to=20 next header processing or it should try to validate the signature in = SEAL=20 header?

 

Thanks - Sreenatha=

     =20

-------------------------------------------= ----------

From: "Templin, Fred L"=20 <Fred.L.Templin@boeing.com>

To: Sreenatha setty=20 <sreenatha.b@huawei.com>,=20 "fltemplin@acm.org"

     =20 <fltemplin@acm.org>

Cc: "ipv6@ietf.org"=20 <ipv6@ietf.org>

Subject: RE: RE:Pre-draft: SEAL as an IPv6= =20 extension header

     =20 (was:Fragmentation-related Security issues)<= /P>

Message-ID:

     =20 <E1829B60731D1740BB7A0626B4FAF0A65C793AF16B@XCH-NW-01V.nw.nos.boei= ng.com>

     =20

Content-Type: text/plain;=20 charset=3D"us-ascii"

 

Hi Sreenatha,

 

Since posting my message, I have submitted = an=20 actual draft that deprecates

the list-posted=20 pre-draft:

 

https://datatracker.ietf.org/doc/draft-temp= lin-sealopt/

 

The posted version makes the observation th= at the=20 source can use the SEAL

option either in coordination with the dest= ination=20 (in which case the source

includes a digital signature that the desti= nation=20 can verify) or independently

from the destination (in which case the sou= rce can=20 include any type of

signature it likes). Your question seems to= stem=20 from the former case:

 

> 1. SEAL IPv6 extension header function= ality=20 is similar to AH header functionality

> which is already standardized in RFC 2= 402(IP=20 Authentication Header). AH header

> also calculates the ICV of the packet= =20 [Section 3.3.3.1.2 ICV Computation for IPv6<= /P>

> in RFC 2402] which is used to check th= e=20 integrity of the packet. So what is the

> advantage of using SEAL header over AH= =20 header?

 

When the source and destination share a sec= ret key=20 used for digital signature

calculation and verification, it is true th= at SEAL=20 somewhat resembles AH.

However, the SEAL source only calculates th= e=20 digital signature over the leading

128 bytes of the packet beginning with the = SEAL=20 header itself. So, unlike AH,

the digital signature does not cover the en= tire=20 packet and does not cover a

pseudo-header of the IPv6=20 header.

 

This has two important implications. First,= when a=20 router on the path needs to

drop an IPv6 packet with a SEAL option and = return=20 an ICMP error message, the

packet-in-error within the ICMP will includ= e=20 enough of the leading portion  of the

SEAL packet so that the source can verify t= hat the=20 ICMP was generated by an

on-path router. The same is not true for AH= , since=20 the AH ICV covers the entire

packet, and the packet-in-error field withi= n the=20 ICMP message may not include

the entire packet. Second, the digital sign= ature=20 will remain valid even if the IPv6

header is subject to network address=20 translation.

 

------------------------------

 

Message: 3

Message-ID:=20 <mailman.1071.1326393779.3200.ipv6@ietf.org><= /FONT>

 

ight

weight data origin authentication and integ= rity=20 checking capability for the

leading 128 bytes of the packet. The=20 Identification field additionally prov=3D

ides

the destination with a means to detect repl= ayed=20 packets. Note that this

provides less authentication assurance than= AH,=20 since a middlebox on the

path could alter the "tail" of the packet b= eyond=20 the leading 128 bytes. But=3D

,

it defeats off-path spoofing=20 attacks.

 

Note again that, when the source and destin= ation=20 are not engaged in a

digital signing and verification relationsh= ip, the=20 source could sign the

message any way it wants, e.g., by writing = a=20 constant or time-varying

nonce. In that case, the destination would = be=20 vulnerable to an off-path

attacker guessing the nonce and hence shoul= d not=20 use the nonce as

a data origin authentication=20 signature.

 

Thanks - Fred

 

PS The number 128 was chosen so that enough= of the=20 packet would be

included to provide sufficient inter-packet= =20 diversity in calculating the di=3D

gital

signature. However, I could also see an arg= uement=20 for a smaller number,

e.g., 64, 80, 96,=20 etc.

 

--_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7BDXCHNW01Vnwnos_-- From Fred.L.Templin@boeing.com Mon Jan 16 07:51:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA48F21F85EF for ; Mon, 16 Jan 2012 07:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcuRDN+RrqFE for ; Mon, 16 Jan 2012 07:51:43 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9D67121F85E4 for ; Mon, 16 Jan 2012 07:51:43 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id q0GFpetf026885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jan 2012 07:51:41 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id q0GFpef8025109; Mon, 16 Jan 2012 07:51:40 -0800 (PST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id q0GFpdsZ025078 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 16 Jan 2012 07:51:40 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 16 Jan 2012 07:51:39 -0800 From: "Templin, Fred L" To: "ipv6@ietf.org" , Sreenatha setty Date: Mon, 16 Jan 2012 07:51:37 -0800 Subject: The SEAL IPv6 Destination Option Thread-Topic: The SEAL IPv6 Destination Option Thread-Index: AczRritoWWU5eFohSYun74sigPsbGwAXpFLAABD05nAAfLHN4AAH6HZQAADIK2A= Message-ID: References: <8F4DB39B04694D3FB200A2F934DF564D@china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7D9XCHNW01Vnwnos_" MIME-Version: 1.0 X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:51:44 -0000 --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7D9XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am renaming this thread to the new title of the document. Here is the abstract and document URL : "The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 destination option that contains a digital signature inserted by the source. The source can thereafter use the signature to verify that any ICMPv6 messages received actually came from a router on the path, while destinations that share a secret key with the source can verify the signature to ensure data origin authentication." https://datatracker.ietf.org/doc/draft-templin-sealopt/ Thanks - Fred fred.l.templin@boeing.com --_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7D9XCHNW01Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I  am rena= ming this=20 thread to the new title of the document. Here is the 
abstract  = and=20 document URL :
 
  "The Subnetwork Encapsulation and Ada= ptation=20 Layer (SEAL) provides a
   mid-layer header designed for the=20 encapsulation of an inner network
   layer packet within outer= =20 network layer headers.  SEAL also supports
   a transport= mode=20 of operation, where the inner payload corresponds to
   an ord= inary=20 transport layer payload.  However, SEAL can also provide
 &nbs= p;=20 benefit when used as an IPv6 destination option that contains a
 &n= bsp;=20 digital signature inserted by the source.  The source can=20 thereafter
   use the signature to verify that any ICMPv6 mess= ages=20 received
   actually came from a router on the path, while=20 destinations that
   share a secret key with the source can ve= rify=20 the signature to ensure
   data origin authentication." 
 

https://da= tatracker.ietf.org/doc/draft-templin-sealopt/ 

 
Thanks - Fred 
fred.l.templin@boeing.com 
--_000_E1829B60731D1740BB7A0626B4FAF0A65C793AF7D9XCHNW01Vnwnos_-- From brian@innovationslab.net Mon Jan 16 12:23:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC8A21F86A5 for ; Mon, 16 Jan 2012 12:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTxL6UQ2cfh1 for ; Mon, 16 Jan 2012 12:23:17 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3706C21F86A3 for ; Mon, 16 Jan 2012 12:23:16 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6EB4E88141; Mon, 16 Jan 2012 12:23:15 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AD1EB13680EB; Mon, 16 Jan 2012 12:23:14 -0800 (PST) Message-ID: <4F148730.6030308@innovationslab.net> Date: Mon, 16 Jan 2012 15:23:12 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 20:23:19 -0000 All, This is a consensus call on adopting: Title : Processing of IPv6 "atomic" fragments Author(s) : Fernando Gont Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt Pages : 12 Date : 2011-12-15 as a 6MAN working group document. Please state your opinion, positive or negative, on the mailing list or to the chairs. This consensus call will end on January 31, 2012. Regards, Brian & Bob From brian@innovationslab.net Mon Jan 16 12:24:38 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C055521F86BA for ; Mon, 16 Jan 2012 12:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTCeFW1iHUub for ; Mon, 16 Jan 2012 12:24:38 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6521F86B8 for ; Mon, 16 Jan 2012 12:24:38 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7B48088141; Mon, 16 Jan 2012 12:24:37 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AA95613680EB; Mon, 16 Jan 2012 12:24:36 -0800 (PST) Message-ID: <4F148782.40704@innovationslab.net> Date: Mon, 16 Jan 2012 15:24:34 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: IPv6 WG Mailing List Subject: Re: Requests for agenda time References: <4F0324A3.6000909@innovationslab.net> In-Reply-To: <4F0324A3.6000909@innovationslab.net> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org> X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 20:24:38 -0000 Just a reminder that the chairs are soliciting requests for agenda time in Paris. On 1/3/12 10:54 AM, Brian Haberman wrote: > All, > The scheduling of WG sessions for IETF 83 has begun. To assist the > chairs in requesting the appropriate amount of time, we are soliciting > requests for agenda time in Paris. As with agenda requests in the past, > please send the chairs (6man-chairs@tools.ietf.org) the following > information: > > 1. Topic > 2. Presenter > 3. Requested amount of time > > Regards, > Brian & Bob From wwwrun@rfc-editor.org Mon Jan 16 15:29:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D261321F86DF for ; Mon, 16 Jan 2012 15:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwBbgetlEiWc for ; Mon, 16 Jan 2012 15:29:04 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 57D2C21F85EF for ; Mon, 16 Jan 2012 15:29:04 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 377C8B1E007; Mon, 16 Jan 2012 15:26:06 -0800 (PST) To: edward.jankiewicz@sri.com, john.loughney@nokia.com, narten@us.ibm.com, rdroms.ietf@gmail.com, jari.arkko@piuha.net, bob.hinden@gmail.com, brian@innovationslab.net Subject: [Editorial Errata Reported] RFC6434 (3091) From: RFC Errata System Message-Id: <20120116232606.377C8B1E007@rfc-editor.org> Date: Mon, 16 Jan 2012 15:26:06 -0800 (PST) Cc: ipv6@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 23:29:05 -0000 The following errata report has been submitted for RFC6434, "IPv6 Node Requirements". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6434&eid=3091 -------------------------------------- Type: Editorial Reported by: Sam Silvester Section: 5.10. Original Text ------------- Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support MLDv2 as defined in [RFC5790]. Corrected Text -------------- Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support Lightweight MLDv2 as defined in [RFC5790]. Notes ----- MLDv2 is RFC3810, and has both INCLUDE and EXCLUDE filter modes (as per previous paragraph. RFC5790 (Lightweight MLDv2) is sufficient for nodes supporting application using only INCLUDE and Any-Source Multicast. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6434 (draft-ietf-6man-node-req-bis-11) -------------------------------------- Title : IPv6 Node Requirements Publication Date : December 2011 Author(s) : E. Jankiewicz, J. Loughney, T. Narten Category : INFORMATIONAL Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG From arifumi@nttv6.net Tue Jan 17 04:44:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350FF21F84A5 for ; Tue, 17 Jan 2012 04:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqLAZ2OpJWAH for ; Tue, 17 Jan 2012 04:44:15 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4052821F849D for ; Tue, 17 Jan 2012 04:44:15 -0800 (PST) Received: from radiko.smartstream.ne.jp (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q0HCgEK5038594; Tue, 17 Jan 2012 21:42:14 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: -06 candidate Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-15-604434390 From: Arifumi Matsumoto In-Reply-To: Date: Tue, 17 Jan 2012 21:39:45 +0900 Message-Id: <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> To: Chris Grundemann X-Mailer: Apple Mail (2.1084) Cc: Tim Chown , 6man Mailing List , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 12:44:18 -0000 --Apple-Mail-15-604434390 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, sorry for the delay. I put together the remaining issues to be fixed in -06 version. Several points, - regarding the site-local deprecation, if I noticed only the examples section should be updated. And, I'm now wondering if the examples should be updated or not. - regarding the informative reference, please tell me how exactly to refer to them in informative way. Let me have your quick look at this, before submission. --Apple-Mail-15-604434390 Content-Disposition: attachment; filename=draft-ietf-6man-rfc3484-revise-06.txt Content-Type: text/plain; name="draft-ietf-6man-rfc3484-revise-06.txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. Matsumoto Internet-Draft J. Kato Intended status: Standards Track T. Fujisaki Expires: July 20, 2012 NTT T. Chown University of Southampton January 17, 2012 Update to RFC 3484 Default Address Selection for IPv6 draft-ietf-6man-rfc3484-revise-06.txt Abstract RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 20, 2012. Copyright Notice Copyright (c) 2012 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 Matsumoto, et al. Expires July 20, 2012 [Page 1] =0C Internet-Draft RFC3484 Bis January 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Specification Changes . . . . . . . . . . . . . . . . . . . . 4 2.1. The default policy table . . . . . . . . . . . . . . . . . 4 2.2. The longest matching rule . . . . . . . . . . . . . . . . 5 2.3. Utilize next-hop for source address selection . . . . . . 5 2.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 5 2.5. Anycast addresses for candidate source addresses . . . . . 5 3. Rathonales for Changes . . . . . . . . . . . . . . . . . . . . 5 3.1. Changes related to the default policy table . . . . . . . 6 3.1.1. ULA in the policy table . . . . . . . . . . . . . . . 6 3.1.2. Teredo in the policy table . . . . . . . . . . . . . . 7 3.1.3. 6to4, Teredo, and IPv4 prioritization . . . . . . . . 7 3.1.4. Deprecated addresses in the policy table . . . . . . . 7 3.2. The longest matching rule . . . . . . . . . . . . . . . . 7 3.3. Utilize next-hop for source address selection . . . . . . 8 3.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 8 3.5. Anycast addresses for candidate source addresses . . . . . 9 3.6. Deprecation of site-local unicast address . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Past Discussion . . . . . . . . . . . . . . . . . . . 11 B.1. The longest match rule . . . . . . . . . . . . . . . . . . 11 B.2. NAT64 prefix issue . . . . . . . . . . . . . . . . . . . . 12 B.3. ISATAP issue . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 12 Matsumoto, et al. Expires July 20, 2012 [Page 2] =0C Internet-Draft RFC3484 Bis January 2012 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Matsumoto, et al. Expires July 20, 2012 [Page 3] =0C Internet-Draft RFC3484 Bis January 2012 1. Introduction The IPv6 addressing architecture [RFC4291] allows multiple unicast addresses to be assigned to interfaces. Because of this IPv6 implementations need to handle multiple possible source and destination addresses when initiating communication. RFC 3484 [RFC3484] specifies the default algorithms, common across all implementations, for selecting source and destination addresses so that it is easier to predict the address selection behavior. Since RFC 3484 was specified, some issues have been identified with the algorithms specified there. The issues include the longest match algorithm used in Rule 9 of destination address selection breaking DNS round-robin techniques, and prioritization of poor IPv6 connectivity using transition mechanisms over native IPv4 connectivity. There have also been some significant changes to the IPv6 addressing architecture that require changes in the RFC 3484 policy table. Such changes include the deprecation of site-local unicast addresses [RFC3879] and of IPv4-compatible IPv6 addresses, and the introduction of Unique Local Addresses [RFC4193]. This document specifies a set of updates that modify the algorithms and fix the known defects. 2. Specification Changes 2.1. The default policy table The default policy table is defined in RFC 3484 Section 2.1. This should be updated to: Prefix Precedence Label ::1/128 60 0 fc00::/7 50 1 ::/0 40 2 ::ffff:0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 ::/96 1 10 fec0::/10 1 11 3ffe::/16 1 12 Matsumoto, et al. Expires July 20, 2012 [Page 4] =0C Internet-Draft RFC3484 Bis January 2012 2.2. The longest matching rule RFC 3484 Section 6 defines the destination address selection rules. The rule 9 of these rules should be updated to: Rule 9: Use longest matching prefix. When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA & Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), then prefer DB. 2.3. Utilize next-hop for source address selection RFC 3484 Section 5 defines the source address selection rules. Between the rule 5 and 6, the rule 5.1 below should be inserted. Rule 5.1: Use an address assigned by the selected next-hop. If SA is assigned by the selected next-hop that will be used to send to D and SB is assigned by a different next-hop, then prefer SA. Similarly, if SB is assigned by the next-hop that will be used to send to D and SA is assigned by a different next-hop, then prefer SB. 2.4. Private IPv4 address scope RFC 3484 Section 3.2 defines the scopes for IPv4 addresses. The sentense that defines the IPv4 private address scope in the second paragraph should be changed as follows. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned global scope. 2.5. Anycast addresses for candidate source addresses RFC 3484 Section 4 defines the candidate source addresses. The eighth paragraph should be updates as follows. In any case, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. 3. Rathonales for Changes Matsumoto, et al. Expires July 20, 2012 [Page 5] =0C Internet-Draft RFC3484 Bis January 2012 3.1. Changes related to the default policy table The default policy table is defined in RFC 3484 Section 2.1 as follows: Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 The changes that should be included into the default policy table are those rules that are universally useful and do no harm in every reasonable network environment. The changes we should consider for the default policy table are listed in this sub-section. The policy table is defined to be configurable. The changes that are useful locally but not universally can be put into the policy table manually or by using the policy distribution mechanism proposed as a DHCP option [I-D.ietf-6man-addr-select-opt]. 3.1.1. ULA in the policy table RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address selection problems related to ULAs [RFC4193]. These problems can be solved by either changing the scope of ULAs to site-local, or by adding an entry for the default policy table that has its own label for ULAs. Centrally assigned ULAs [I-D.ietf-ipv6-ula-central] have been proposed, and are assigned fc00::/8. Using the different labels for fc00::/8 and fd00::/8 makes sense if we assume the same kind of address block is assigned in the same or adjacent network. However, we cannot expect that the type of ULA address block and network adjacency commonly have any relationships. Regarding the scope of ULAs, ULAs have been specified with a global scope because the reachability of ULAs was intended to be restricted by the routing system. Since the ULAs will not be exposed outside of their reachability domain, if a ULA is available as a candidate destination address, it can be expected to be reachable. If we change the scope of ULAs to be smaller than global, we can prioritize ULA to ULA communication over GUA to GUA communication. At the same time, however, finer-grained configuration of ULA address selection will be impossible. For example, even if you want to prioritize communication related to the only /48 ULA prefix used in Matsumoto, et al. Expires July 20, 2012 [Page 6] =0C Internet-Draft RFC3484 Bis January 2012 your site, and do not want to prioritize communication to any other ULA prefix, such a policy cannot be implemented in the policy table. So, this draft proposes the use of the policy table to differentiate ULAs from GUAs. 3.1.2. Teredo in the policy table Teredo [RFC4380] is defined and has been assigned 2001::/32. This address block should be assigned its own label in the policy table. Teredo's priority should be less than or equal to 6to4, considering its characteristic of being a transitional tunnel mechanism. 3.1.3. 6to4, Teredo, and IPv4 prioritization Regarding the prioritization between IPv4 and these transitional mechanisms, their connectivity is known to usually be worse than IPv4. These mechanisms are said to be the last resort access method to IPv6 resources. 6to4 should have higher precedence than Teredo, given that 6to4 host to 6to4 host communication can be over IPv4 (which can result in a more optimal path) and that 6to4 should not used behind a NAT device. 3.1.4. Deprecated addresses in the policy table IPv4-compatible IPv6 addresses (::/96) are deprecated [RFC4291]. IPv6 site-local unicast addresses (fec0::/10) are deprecated [RFC3879]. 6bone testing addresses [RFC3701] has also been phased out. These addresses were removed from the current specification. Considering the inappropriate use of these address blocks, especially in outdated implementations and bad effects brought by them, they should be labeled differently from the legitimate address blocks as long as the address block is reserved by IANA. 3.2. The longest matching rule This issue is related to the longest matching rule, which was found by Dave Thaler. It causes a malfunction of the DNS round robin technique, as described below. It is common for both IPv4 and IPv6. When a destination address DA, DB, and the source address of DA Source(DA) are on the same subnet and Source(DA) =3D=3D Source(DB), = DNS round robin load-balancing cannot function. By considering prefix lengths that are longer than the subnet prefix, this rule establishes preference between addresses that have no substantive differences between them. The rule functions as an arbitrary tie-breaker between the hosts in a round robin, causing a given host to always prefer a Matsumoto, et al. Expires July 20, 2012 [Page 7] =0C Internet-Draft RFC3484 Bis January 2012 given member of the round robin. By limiting the calculation of common prefixes to a maximum length equal to the length of the subnet prefix of the source address, rule 9 can continue to favor hosts that are nearby in the network hierarchy without arbitrarily sorting addresses within a given network. 3.3. Utilize next-hop for source address selection RFC 3484 source address selection rule 5 says that the address that is attached to the outgoing interface should be preferred as the source address. This rule is reasonable considering the prevalence of ingress filtering described in BCP 38 [RFC2827]. This is because an upstream network provider usually assumes it receives packets from their customer that only have the delegated addresses as the source addresses. This rule, however, is not effective in an environment such as that described in RFC 5220 Section 2.1.1, where a host has multiple upstream routers on the same link and has addresses delegated from each upstream router on a single interface. Also, DHCPv6 assigned addresses are not associated like SLAAC assigned addresses to a next-hop gateway, so implementations usually can't apply this heuristic in a DHCPv6 network. So, a new rule 5.1 that utilizes next-hop information for source address selection is inserted just after rule 5. 3.4. Private IPv4 address scope When a packet goes through a NAT, its source or destination address can get replaced with another address with a different scope. It follows that the result of the source address selection algorithm may be different when the original address is replaced with the NATed address. The algorithm currently specified in RFC 3484 is based on the assumption that a source address with a small scope cannot reach a destination address with a larger scope. This assumption does not hold if private IPv4 addresses and a NAT are used to reach public IPv4 addresses. Due to this assumption, in the presence of both a NATed private IPv4 address and a transitional address (like 6to4 or Teredo), the host will choose the transitional IPv6 address to access dual-stack peers [I-D.denis-v6ops-nat-addrsel]. Choosing transitional IPv6 Matsumoto, et al. Expires July 20, 2012 [Page 8] =0C Internet-Draft RFC3484 Bis January 2012 connectivity over native IPv4 connectivity, particularly where the transitional connectivity is unmanaged, is not considered to be generally desirable. This issue can be fixed by changing the address scope of private IPv4 addresses to global. 3.5. Anycast addresses for candidate source addresses RFC 3484 Section 4 states that anycast addresses, as well as multicast addresses and the unspecified address, MUST NOT be included in a candidate set of source address. Now that RFC 4291 Section 2.6 [RFC4291] removed the restrictions on using IPv6 anycast addresses as the source address of an IPv6 packet, this restriction of RFC 3484 should also be removed. 3.6. Deprecation of site-local unicast address RFC 3484 contains a few "site-local unicast" and "fec0::" descriptions. It's better to remove examples related to site-local unicast addresses, or change the examples to use ULAs. Possible points to be re-written are listed below. - RFC 3484 Section 10 contains examples for site-local addresses. 4. Security Considerations No security risk is found that degrades RFC 3484. 5. IANA Considerations Address type number for the policy table may have to be assigned by IANA. 6. References 6.1. Normative References [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. Matsumoto, et al. Expires July 20, 2012 [Page 9] =0C Internet-Draft RFC3484 Bis January 2012 [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004. [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi- Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008. 6.2. Informative References [I-D.chown-addr-select-considerations] Chown, T., "Considerations for IPv6 Address Selection Policy Changes", draft-chown-addr-select-considerations-03 (work in progress), July 2009. [I-D.denis-v6ops-nat-addrsel] Denis-Courmont, R., "Problems with IPv6 source address selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 (work in progress), February 2009. [I-D.ietf-6man-addr-select-opt] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", draft-ietf-6man-addr-select-opt-01 (work in progress), June 2011. [I-D.ietf-ipv6-ula-central] Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast Matsumoto, et al. Expires July 20, 2012 [Page 10] =0C Internet-Draft RFC3484 Bis January 2012 Addresses", draft-ietf-ipv6-ula-central-02 (work in progress), June 2007. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Appendix A. Acknowledgements Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- Courmont, Francois-Xavier Le Bail, and the members of 6man's address selection design team for their invaluable contributions to this document. Appendix B. Past Discussion This section summarizes discussions we had before related to address selection mechanisms. B.1. The longest match rule RFC 3484 defines that destination address selection rule 9 should be applied to both IPv4 and IPv6, which spoils the DNS-based load balancing technique that is widely used in the IPv4 Internet today. When two or more destination addresses are acquired from one FQDN, rule 9 states that the longest matching destination and source address pair should be chosen. As in RFC 1794, the DNS-based load balancing technique is achieved by not re-ordering the destination addresses returned from the DNS server. Rule 9 defines a deterministic rule for re-ordering hosts, hence the technique described in RFC 1794 is not available anymore. Regarding this problem, there was discussion in IETF and other places like below. Discussion: The possible changes to RFC 3484 are as follows: 1. To delete Rule 9 completely. 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, hierarchical address assignment generally used at present, hence the longest matching rule is beneficial in many cases. In IPv4, Matsumoto, et al. Expires July 20, 2012 [Page 11] =0C Internet-Draft RFC3484 Bis January 2012 as stated above, the DNS based load balancing technique is widely used. 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When the length of matching bits of the destination address and the source address is longer than N, rule 9 is applied. Otherwise, the order of the destination addresses do not change. The value of N should be configurable and it should be 32 by default. This is simply because the two sites whose matching bit length is longer than 32 are probably adjacent. Now that IPv6 PI addresses are being introduced by RIRs, hierarchical address assignment is not always maintained anymore. It seems that the longest matching algorithm may not worth the adverse effect of disabling the DNS-based load balance technique. B.2. NAT64 prefix issue The NAT64 WKP has recently been defined[RFC6052]. It depends site by site whether NAT64 should be preferred over IPv4, in other words NAT44, or NAT44 over NAT64. So, the issue of local site policy should be solved by manual policy table changes locally, or by use of the proposed DHCP-based policy distribution mechanism. B.3. ISATAP issue Where a site is using ISATAP [RFC5214], there is generally no way to differentiate an ISATAP address from a native address without interface information. However, a site will assign a prefix for its ISATAP overlay, and can choose to add an entry for that prefix to the policy table if it wishes to change the default preference for that prefix. Appendix C. Revision History 06: Specification changes and rationales for changes are separated. 05: 6bone testing addresses were back in the default policy table. Section 2.6 for allowing anycast source address were added. 04: Added comment about ISATAP. 03: Matsumoto, et al. Expires July 20, 2012 [Page 12] =0C Internet-Draft RFC3484 Bis January 2012 ULA address selection issue was expanded. 6to4, Teredo and IPv4 prioritization issue was elaborated. Deprecated address blocks in policy table section was elaborated. In appendix, NAT64 prefix issue was added. 02: Suresh Krishnan's suggestions for better english sentences were incorporated. A new source address selection rule that utilizes the next-hop information is included in Section 2.3. Site local address prefix was corrected. 01: Re-structured to contain only the actual changes to RFC 3484. 00: Published as a 6man working group item. 03: Added acknowledgements. Added longest matching algorithm malfunction regarding local DNS round robin. The proposed changes section was re-structured. The issue of 6to4/Teredo and IPv4 prioritization was included. The issue of deprecated addresses was added. The renewed default policy table was changed accordingly. 02: Added the reference to address selection design team's proposal. 01: The issue of private IPv4 address scope was added. The issue of ULA address scope was added. Discussion of longest matching rule was expanded. Authors' Addresses Arifumi Matsumoto NTT SI Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net Matsumoto, et al. Expires July 20, 2012 [Page 13] =0C Internet-Draft RFC3484 Bis January 2012 Jun-ya Kato NTT SI Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 2939 Email: kato@syce.net Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7351 Email: fujisaki@syce.net Tim Chown University of Southampt on Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Matsumoto, et al. Expires July 20, 2012 [Page 14] =0C --Apple-Mail-15-604434390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012/01/13, at 5:24, Chris Grundemann wrote: > On Fri, Dec 16, 2011 at 03:49, Tim Chown wrote: >> Well, there are two questions here. >>=20 >> One is whether the WG believes the update as described in = draft-ietf-6man-rfc3484-revise-05 is correct and complete. I have not = seen (yet) any significant technical concerns raised. The last of those = were discussed and (we believe) resolved in Quebec. Are there any more? >=20 > It appears that there is general agreement here, with possibly a few > technical/content nits that probably need to be sorted in a final > revision, raised by Dave and documented in message: > https://www.ietf.org/mail-archive/web/ipv6/current/msg14984.html >=20 >> The other is whether the WG believes we should publish an update, or = a complete fresh version of RFC3484. This was discussed previously in = the WG and the update path preferred. If a fresh version is now deemed = more appropriate, I am fine to work on that with the other authors if = required. >=20 > My understanding is that there is also general agreement here; that > this should be published as an update (after being re-organized a bit) > now, and then followed up with a replace (bis) I-D. As I have > previously stated; the changes in this update are needed and are > time-sensitive, the sooner this update can become an RFC the better. >=20 >> We just need a decision so we can progress this - it's been so close = to release for a long time. Many of the changes in the update have been = implemented in a number of platforms already. >=20 > Agreed, let's get this done! =3D) >=20 > Cheers, > ~Chris >=20 > PS - I don't want to step on any toes here, but I'd be happy to take a > stab at a revision based on the current feedback if the authors would > like, I could probably get it done by the end of next week, possibly > sooner. >=20 >> Tim >=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 >=20 >=20 > --=20 > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 --Apple-Mail-15-604434390-- From brian@innovationslab.net Tue Jan 17 10:16:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BCB21F84D7 for ; Tue, 17 Jan 2012 10:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JuBZrhzZU-3 for ; Tue, 17 Jan 2012 10:16:43 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1639D21F8463 for ; Tue, 17 Jan 2012 10:16:42 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 2C87E88130; Tue, 17 Jan 2012 10:16:40 -0800 (PST) Received: from clemson.local (unknown [75.94.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 98DA91368114; Tue, 17 Jan 2012 10:16:38 -0800 (PST) Message-ID: <4F15BB0C.5040108@innovationslab.net> Date: Tue, 17 Jan 2012 13:16:44 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: RFC Errata System Subject: Re: [Editorial Errata Reported] RFC6434 (3091) References: <20120116232606.377C8B1E007@rfc-editor.org> In-Reply-To: <20120116232606.377C8B1E007@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, narten@us.ibm.com, ipv6@ietf.org, bob.hinden@gmail.com, rdroms.ietf@gmail.com X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:16:43 -0000 On 1/16/12 6:26 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6434, > "IPv6 Node Requirements". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6434&eid=3091 > > -------------------------------------- > Type: Editorial > Reported by: Sam Silvester > > Section: 5.10. > > Original Text > ------------- > Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support MLDv2 as defined in [RFC5790]. > > Corrected Text > -------------- > Nodes supporting applications that expect to only take advantage of MLDv2's INCLUDE functionality as well as Any-Source Multicast will find it sufficient to support Lightweight MLDv2 as defined in [RFC5790]. > > Notes > ----- > MLDv2 is RFC3810, and has both INCLUDE and EXCLUDE filter modes (as per previous paragraph. > > RFC5790 (Lightweight MLDv2) is sufficient for nodes supporting application using only INCLUDE and Any-Source Multicast. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6434 (draft-ietf-6man-node-req-bis-11) > -------------------------------------- > Title : IPv6 Node Requirements > Publication Date : December 2011 > Author(s) : E. Jankiewicz, J. Loughney, T. Narten > Category : INFORMATIONAL > Source : IPv6 Maintenance > Area : Internet > Stream : IETF > Verifying Party : IESG I am not sure there is a benefit to adding a single adjective to the noted sentence. The actual reference is correct, so the reader will be correctly directed to the Lightweight MLD specification. Regards, Brian From sam.silvester@gmail.com Tue Jan 17 13:36:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8011E80BD for ; Tue, 17 Jan 2012 13:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNPAZFJVSFHU for ; Tue, 17 Jan 2012 13:36:08 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B17B11E80B2 for ; Tue, 17 Jan 2012 13:36:08 -0800 (PST) Received: by wgbdq11 with SMTP id dq11so1779966wgb.13 for ; Tue, 17 Jan 2012 13:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BGiRwFQGGTxyu8wyRP7nxeouVM+j5ADznMRkXnF2mhA=; b=muPwzNqq+6hZTcUrLoBvjlA9hasvAa395j65ENi7FMuwyrJZkg5d8C4ODqlAyzBx3S tmhZ4WZqc3NxRFwM4J6NTe6AKF+7icSJD3Y/HLELpMDeryhEs3WbrXbr2kcHJ0G3rSkX HVvGKAb0GsZ/XbrO58HXuKeXrL/tgst0Zkwbg= MIME-Version: 1.0 Received: by 10.180.19.138 with SMTP id f10mr39195128wie.3.1326836167745; Tue, 17 Jan 2012 13:36:07 -0800 (PST) Received: by 10.223.157.194 with HTTP; Tue, 17 Jan 2012 13:36:07 -0800 (PST) In-Reply-To: <4F15BB0C.5040108@innovationslab.net> References: <20120116232606.377C8B1E007@rfc-editor.org> <4F15BB0C.5040108@innovationslab.net> Date: Wed, 18 Jan 2012 08:06:07 +1030 Message-ID: Subject: Re: [Editorial Errata Reported] RFC6434 (3091) From: Sam Silvester To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: john.loughney@nokia.com, narten@us.ibm.com, ipv6@ietf.org, bob.hinden@gmail.com, rdroms.ietf@gmail.com, RFC Errata System X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:36:10 -0000 On Wed, Jan 18, 2012 at 4:46 AM, Brian Haberman wrote: > > I am not sure there is a benefit to adding a single adjective to the note= d > sentence. =A0The actual reference is correct, so the reader will be corre= ctly > directed to the Lightweight MLD specification. > > Regards, > Brian Fair enough. My understanding was that "Lightweight MLDv2" is the name of the RFC in the reference, as such shouldn't we be getting it right - especially in the sense that the name is close enough to MLDv2 and therefore avoiding confusion would be a good thing? i.e. it's less an adjective - if we're referring to an RFC, we should do it properly - especially when there is another, similar and related RFC that is also being discussed in the same paragraph? If only because it made me stop, get a little confused and have to go back and re-read the section (hence the Errata!) to get it clear in my mind what was going on. Regards, Sam From marka@isc.org Tue Jan 17 14:27:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BD421F86A2 for ; Tue, 17 Jan 2012 14:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOvVYl-F1bMb for ; Tue, 17 Jan 2012 14:27:10 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3221F8585 for ; Tue, 17 Jan 2012 14:27:09 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 961425F98EA; Tue, 17 Jan 2012 22:26:57 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7034:c5d9:cda5:d5c0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 78CAD216C6A; Tue, 17 Jan 2012 22:26:55 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 99F9C1B88A6D; Wed, 18 Jan 2012 09:26:53 +1100 (EST) To: Arifumi Matsumoto From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> Subject: Re: -06 candidate In-reply-to: Your message of "Tue, 17 Jan 2012 21:39:45 +0900." <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> Date: Wed, 18 Jan 2012 09:26:53 +1100 Message-Id: <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> Cc: 6man Mailing List , Tim Chown , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:27:10 -0000 ULA need to be de-preferenced except for the local ULA prefixes. Below is what I use in FreeBSD 8. It keeps local traffic using fd92:7065:b8e::/48 rather than using the PA address. If you learn a ULA destination address that is not local YOU DO NOT WANT TO USE IT by default when you have another choice. What you do want is for a interface when it learns a ULA address to add the corresponding /48 prefix with a given precedence and a unique label to the table if the prefix does not exist. And appropriate cleaning be done when no more interfaces exist in the /48. This may require a manual tag on table entries. Mark > more /etc/ip6addrctl.conf #Prefix Prec Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0.0.0.0/96 35 4 fd92:7065:b8e::/48 45 5 fc00::/7 5 6 > ifconfig nfe0 inet6 nfe0: flags=8843 metric 0 mtu 1500 options=82008 inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From arifumi@nttv6.net Tue Jan 17 18:26:50 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D2021F8607 for ; Tue, 17 Jan 2012 18:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OxJHHOLfRJ4 for ; Tue, 17 Jan 2012 18:26:48 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEF521F84B5 for ; Tue, 17 Jan 2012 18:26:44 -0800 (PST) Received: from radiko.smartstream.ne.jp (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q0I2OacQ045171; Wed, 18 Jan 2012 11:24:36 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: -06 candidate Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-18-653778045 From: Arifumi Matsumoto In-Reply-To: <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> Date: Wed, 18 Jan 2012 11:22:08 +0900 Message-Id: <1A3D7349-E7B1-42D0-AE81-5CC73A1B00B7@nttv6.net> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> To: Arifumi Matsumoto X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Tim Chown , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:26:50 -0000 --Apple-Mail-18-653778045 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Oops, I attached an old version. Here is the newer one. --Apple-Mail-18-653778045 Content-Disposition: attachment; filename="draft-ietf-6man-rfc3484-revise-06(1).txt" Content-Type: text/plain; name="draft-ietf-6man-rfc3484-revise-06(1).txt" Content-Transfer-Encoding: quoted-printable Network Working Group A. Matsumoto Internet-Draft J. Kato Intended status: Standards Track T. Fujisaki Expires: July 20, 2012 NTT T. Chown University of Southampton January 17, 2012 Update to RFC 3484 Default Address Selection for IPv6 draft-ietf-6man-rfc3484-revise-06.txt Abstract RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 20, 2012. Copyright Notice Copyright (c) 2012 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 Matsumoto, et al. Expires July 20, 2012 [Page 1] =0C Internet-Draft RFC3484 Bis January 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Specification Changes . . . . . . . . . . . . . . . . . . . . 4 2.1. The default policy table . . . . . . . . . . . . . . . . . 4 2.2. The longest matching rule . . . . . . . . . . . . . . . . 5 2.3. Utilize next-hop for source address selection . . . . . . 5 2.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 5 2.5. Anycast addresses for candidate source addresses . . . . . 5 3. Rathonales for Changes . . . . . . . . . . . . . . . . . . . . 5 3.1. Changes related to the default policy table . . . . . . . 6 3.1.1. ULA in the policy table . . . . . . . . . . . . . . . 6 3.1.2. Teredo in the policy table . . . . . . . . . . . . . . 7 3.1.3. 6to4, Teredo, and IPv4 prioritization . . . . . . . . 7 3.1.4. Deprecated addresses in the policy table . . . . . . . 7 3.2. The longest matching rule . . . . . . . . . . . . . . . . 7 3.3. Utilize next-hop for source address selection . . . . . . 8 3.4. Private IPv4 address scope . . . . . . . . . . . . . . . . 8 3.5. Anycast addresses for candidate source addresses . . . . . 9 3.6. Deprecation of site-local unicast address . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Past Discussion . . . . . . . . . . . . . . . . . . . 11 B.1. The longest match rule . . . . . . . . . . . . . . . . . . 11 B.2. NAT64 prefix issue . . . . . . . . . . . . . . . . . . . . 12 B.3. ISATAP issue . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix C. Revision History . . . . . . . . . . . . . . . . . . 12 Matsumoto, et al. Expires July 20, 2012 [Page 2] =0C Internet-Draft RFC3484 Bis January 2012 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Matsumoto, et al. Expires July 20, 2012 [Page 3] =0C Internet-Draft RFC3484 Bis January 2012 1. Introduction The IPv6 addressing architecture [RFC4291] allows multiple unicast addresses to be assigned to interfaces. Because of this IPv6 implementations need to handle multiple possible source and destination addresses when initiating communication. RFC 3484 [RFC3484] specifies the default algorithms, common across all implementations, for selecting source and destination addresses so that it is easier to predict the address selection behavior. Since RFC 3484 was specified, some issues have been identified with the algorithms specified there. The issues include the longest match algorithm used in Rule 9 of destination address selection breaking DNS round-robin techniques, and prioritization of poor IPv6 connectivity using transition mechanisms over native IPv4 connectivity. There have also been some significant changes to the IPv6 addressing architecture that require changes in the RFC 3484 policy table. Such changes include the deprecation of site-local unicast addresses [RFC3879] and of IPv4-compatible IPv6 addresses, and the introduction of Unique Local Addresses [RFC4193]. This document specifies a set of updates that modify the algorithms and fix the known defects. 2. Specification Changes 2.1. The default policy table The default policy table is defined in RFC 3484 Section 2.1. This is updated to: Prefix Precedence Label ::1/128 50 0 fc00::/7 45 6 ::/0 40 1 ::ffff:0:0/96 30 4 2002::/16 10 2 2001::/32 5 5 ::/96 1 10 fec0::/10 1 11 3ffe::/16 1 12 Matsumoto, et al. Expires July 20, 2012 [Page 4] =0C Internet-Draft RFC3484 Bis January 2012 2.2. The longest matching rule RFC 3484 Section 6 defines the destination address selection rules. The rule 9 of these rules are updated to: Rule 9: Use longest matching prefix. When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA & Netmask(Source(DA)), Source(DA)) > CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA & Netmask(Source(DA)), Source(DA)) < CommonPrefixLen(DB & Netmask(Source(DB)), Source(DB)), then prefer DB. 2.3. Utilize next-hop for source address selection RFC 3484 Section 5 defines the source address selection rules. Between the rule 5 and 6, the rule 5.1 below is inserted. Rule 5.1: Prefer addresses in a prefix advertised by the next-hop If SA or SA's prefix is assigned by the selected next-hop that will be used to send to D and SB or SB's prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB's prefix is assigned by the next-hop that will be used to send to D and SA or SA's prefix is assigned by a different next-hop, then prefer SB. 2.4. Private IPv4 address scope RFC 3484 Section 3.2 defines the scopes for IPv4 addresses. The sentense that defines the IPv4 private address scope in the second paragraph is changed as follows. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned global scope. 2.5. Anycast addresses for candidate source addresses RFC 3484 Section 4 defines the candidate source addresses. The eighth paragraph is updated as follows. In any case, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. 3. Rathonales for Changes Matsumoto, et al. Expires July 20, 2012 [Page 5] =0C Internet-Draft RFC3484 Bis January 2012 3.1. Changes related to the default policy table The default policy table is defined in RFC 3484 Section 2.1 as follows: Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 The changes that should be included into the default policy table are those rules that are universally useful and do no harm in every reasonable network environment. The changes we should consider for the default policy table are listed in this sub-section. The policy table is defined to be configurable. The changes that are useful locally but not universally can be put into the policy table manually or by using the policy distribution mechanism. One of such mechanisms is proposed as a DHCP option [I-D.ietf-6man-addr-select-opt]. 3.1.1. ULA in the policy table RFC 5220 [RFC5220] sections 2.1.4, 2.2.2, and 2.2.3 describe address selection problems related to ULAs [RFC4193]. These problems can be solved by either changing the scope of ULAs to site-local, or by adding an entry for the default policy table that has its own label for ULAs. Centrally assigned ULAs have been proposed, and are assigned fc00::/8, as described in [I-D.ietf-ipv6-ula-central]. Using the different labels for fc00::/8 and fd00::/8 makes sense if we assume the same kind of address block is assigned in the same or adjacent network. However, we cannot expect that the type of ULA address block and network adjacency commonly have any relationships. Regarding the scope of ULAs, ULAs have been specified with a global scope because the reachability of ULAs was intended to be restricted by the routing system. Since the ULAs will not be exposed outside of their reachability domain, if a ULA is available as a candidate destination address, it can be expected to be reachable. If we change the scope of ULAs to be smaller than global, we can prioritize ULA to ULA communication over GUA to GUA communication. At the same time, however, finer-grained configuration of ULA address selection will be impossible. For example, even if you want to Matsumoto, et al. Expires July 20, 2012 [Page 6] =0C Internet-Draft RFC3484 Bis January 2012 prioritize communication related to the only /48 ULA prefix used in your site, and do not want to prioritize communication to any other ULA prefix, such a policy cannot be implemented in the policy table. So, this document adopted the use of the policy table to differentiate ULAs from GUAs. 3.1.2. Teredo in the policy table Teredo [RFC4380] is defined and has been assigned 2001::/32. This address block should be assigned its own label in the policy table. Teredo's priority should be less than or equal to 6to4, considering its characteristic of being a transitional tunnel mechanism. 3.1.3. 6to4, Teredo, and IPv4 prioritization Regarding the prioritization between IPv4 and these transitional mechanisms, their connectivity is known to usually be worse than IPv4. These mechanisms are said to be the last resort access method to IPv6 resources. 6to4 should have higher precedence than Teredo, given that 6to4 host to 6to4 host communication can be over IPv4 (which can result in a more optimal path) and that 6to4 should not used behind a NAT device. 3.1.4. Deprecated addresses in the policy table IPv4-compatible IPv6 addresses (::/96) are deprecated [RFC4291]. IPv6 site-local unicast addresses (fec0::/10) are deprecated [RFC3879]. 6bone testing addresses [RFC3701] has also been phased out. These addresses were removed from the current specification. Considering the inappropriate use of these address blocks, especially in outdated implementations and bad effects brought by them, they should be labeled differently from the legitimate address blocks as long as the address block is reserved by IANA. 3.2. The longest matching rule This issue is related to the longest matching rule, which was found by Dave Thaler. It causes a malfunction of the DNS round robin technique, as described below. It is common for both IPv4 and IPv6. When a destination address DA, DB, and the source address of DA Source(DA) are on the same subnet and Source(DA) =3D=3D Source(DB), = DNS round robin load-balancing cannot function. By considering prefix lengths that are longer than the subnet prefix, this rule establishes preference between addresses that have no substantive differences between them. The rule functions as an arbitrary tie-breaker between Matsumoto, et al. Expires July 20, 2012 [Page 7] =0C Internet-Draft RFC3484 Bis January 2012 the hosts in a round robin, causing a given host to always prefer a given member of the round robin. By limiting the calculation of common prefixes to a maximum length equal to the length of the subnet prefix of the source address, rule 9 continues to favor hosts that are nearby in the network hierarchy without arbitrarily sorting addresses within a given network. 3.3. Utilize next-hop for source address selection RFC 3484 source address selection rule 5 says that the address that is attached to the outgoing interface should be preferred as the source address. This rule is reasonable considering the prevalence of ingress filtering described in BCP 38 [RFC2827]. This is because an upstream network provider usually assumes it receives packets from their customer that only have the delegated addresses as the source addresses. This rule, however, is not effective in an environment such as that described in RFC 5220 Section 2.1.1, where a host has multiple upstream routers on the same link and has addresses delegated from each upstream router on a single interface. Also, DHCPv6 assigned addresses are not associated like SLAAC assigned addresses to a next-hop gateway, so implementations usually can't apply this heuristic in a DHCPv6 network. In order to implement this rule, a host has to remember who it got an on-link prefix from. 3.4. Private IPv4 address scope When a packet goes through a NAT, its source or destination address can get replaced with another address with a different scope. It follows that the result of the source address selection algorithm may be different when the original address is replaced with the NATed address. The algorithm currently specified in RFC 3484 is based on the assumption that a source address with a small scope cannot reach a destination address with a larger scope. This assumption does not hold if private IPv4 addresses and a NAT are used to reach public IPv4 addresses. Due to this assumption, in the presence of both a NATed private IPv4 address and a transitional address (like 6to4 or Teredo), the host will choose the transitional IPv6 address to access dual-stack peers, as described in [I-D.denis-v6ops-nat-addrsel]. Choosing transitional Matsumoto, et al. Expires July 20, 2012 [Page 8] =0C Internet-Draft RFC3484 Bis January 2012 IPv6 connectivity over native IPv4 connectivity, particularly where the transitional connectivity is unmanaged, is not considered to be generally desirable. This issue is fixed by changing the address scope of private IPv4 addresses to global. 3.5. Anycast addresses for candidate source addresses RFC 3484 Section 4 states that anycast addresses, as well as multicast addresses and the unspecified address, MUST NOT be included in a candidate set of source address. Now that RFC 4291 Section 2.6 [RFC4291] removed the restrictions on using IPv6 anycast addresses as the source address of an IPv6 packet, this restriction of RFC 3484 should also be removed. 3.6. Deprecation of site-local unicast address RFC 3484 contains a few "site-local unicast" and "fec0::" descriptions. It's better to remove examples related to site-local unicast addresses, or change the examples to use ULAs. Possible points to be re-written are listed below. - RFC 3484 Section 10 contains examples for site-local addresses. 4. Security Considerations No security risk is found that degrades RFC 3484. 5. IANA Considerations Address type number for the policy table may have to be assigned by IANA. 6. References 6.1. Normative References [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. Matsumoto, et al. Expires July 20, 2012 [Page 9] =0C Internet-Draft RFC3484 Bis January 2012 [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address Allocation) Phaseout", RFC 3701, March 2004. [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008. [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi- Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008. 6.2. Informative References [I-D.chown-addr-select-considerations] Chown, T., "Considerations for IPv6 Address Selection Policy Changes", draft-chown-addr-select-considerations-03 (work in progress), July 2009. [I-D.denis-v6ops-nat-addrsel] Denis-Courmont, R., "Problems with IPv6 source address selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 (work in progress), February 2009. [I-D.ietf-6man-addr-select-opt] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", draft-ietf-6man-addr-select-opt-01 (work in progress), June 2011. [I-D.ietf-ipv6-ula-central] Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast Matsumoto, et al. Expires July 20, 2012 [Page 10] =0C Internet-Draft RFC3484 Bis January 2012 Addresses", draft-ietf-ipv6-ula-central-02 (work in progress), June 2007. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Appendix A. Acknowledgements Authors would like to thank to Dave Thaler, Pekka Savola, Remi Denis- Courmont, Francois-Xavier Le Bail, and the members of 6man's address selection design team for their invaluable contributions to this document. Appendix B. Past Discussion This section summarizes discussions we had before related to address selection mechanisms. B.1. The longest match rule RFC 3484 defines that destination address selection rule 9 should be applied to both IPv4 and IPv6, which spoils the DNS-based load balancing technique that is widely used in the IPv4 Internet today. When two or more destination addresses are acquired from one FQDN, rule 9 states that the longest matching destination and source address pair should be chosen. As in RFC 1794, the DNS-based load balancing technique is achieved by not re-ordering the destination addresses returned from the DNS server. Rule 9 defines a deterministic rule for re-ordering hosts, hence the technique described in RFC 1794 is not available anymore. Regarding this problem, there was discussion in IETF and other places like below. Discussion: The possible changes to RFC 3484 are as follows: 1. To delete Rule 9 completely. 2. To apply Rule 9 only for IPv6 and not for IPv4. In IPv6, hierarchical address assignment generally used at present, hence the longest matching rule is beneficial in many cases. In IPv4, Matsumoto, et al. Expires July 20, 2012 [Page 11] =0C Internet-Draft RFC3484 Bis January 2012 as stated above, the DNS based load balancing technique is widely used. 3. To apply Rule 9 for IPv6 conditionally and not for IPv4. When the length of matching bits of the destination address and the source address is longer than N, rule 9 is applied. Otherwise, the order of the destination addresses do not change. The value of N should be configurable and it should be 32 by default. This is simply because the two sites whose matching bit length is longer than 32 are probably adjacent. Now that IPv6 PI addresses are being introduced by RIRs, hierarchical address assignment is not always maintained anymore. It seems that the longest matching algorithm may not worth the adverse effect of disabling the DNS-based load balance technique. B.2. NAT64 prefix issue The NAT64 WKP has recently been defined[RFC6052]. It depends site by site whether NAT64 should be preferred over IPv4, in other words NAT44, or NAT44 over NAT64. So, the issue of local site policy should be solved by manual policy table changes locally, or by use of the proposed DHCP-based policy distribution mechanism. B.3. ISATAP issue Where a site is using ISATAP [RFC5214], there is generally no way to differentiate an ISATAP address from a native address without interface information. However, a site will assign a prefix for its ISATAP overlay, and can choose to add an entry for that prefix to the policy table if it wishes to change the default preference for that prefix. Appendix C. Revision History 06: Specification changes and rationales for changes are separated. The precedence and label values in the policy table are changed. 05: 6bone testing addresses were back in the default policy table. Section 2.6 for allowing anycast source address were added. 04: Matsumoto, et al. Expires July 20, 2012 [Page 12] =0C Internet-Draft RFC3484 Bis January 2012 Added comment about ISATAP. 03: ULA address selection issue was expanded. 6to4, Teredo and IPv4 prioritization issue was elaborated. Deprecated address blocks in policy table section was elaborated. In appendix, NAT64 prefix issue was added. 02: Suresh Krishnan's suggestions for better english sentences were incorporated. A new source address selection rule that utilizes the next-hop information is included in Section 2.3. Site local address prefix was corrected. 01: Re-structured to contain only the actual changes to RFC 3484. 00: Published as a 6man working group item. 03: Added acknowledgements. Added longest matching algorithm malfunction regarding local DNS round robin. The proposed changes section was re-structured. The issue of 6to4/Teredo and IPv4 prioritization was included. The issue of deprecated addresses was added. The renewed default policy table was changed accordingly. 02: Added the reference to address selection design team's proposal. 01: The issue of private IPv4 address scope was added. The issue of ULA address scope was added. Discussion of longest matching rule was expanded. Matsumoto, et al. Expires July 20, 2012 [Page 13] =0C Internet-Draft RFC3484 Bis January 2012 Authors' Addresses Arifumi Matsumoto NTT SI Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net Jun-ya Kato NTT SI Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 2939 Email: kato@syce.net Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7351 Email: fujisaki@syce.net Tim Chown University of Southampt on Southampton, Hampshire SO17 1BJ United Kingdom Email: tjc@ecs.soton.ac.uk Matsumoto, et al. Expires July 20, 2012 [Page 14] =0C --Apple-Mail-18-653778045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012/01/17, at 21:39, Arifumi Matsumoto wrote: > Hi, >=20 > sorry for the delay. > I put together the remaining issues to be fixed in -06 version. >=20 > Several points, >=20 > - regarding the site-local deprecation, if I noticed only the examples > section should be updated. And, I'm now wondering if the examples > should be updated or not. >=20 > - regarding the informative reference, please tell me how exactly to > refer to them in informative way. >=20 > Let me have your quick look at this, before submission. >=20 > > On 2012/01/13, at 5:24, Chris Grundemann wrote: >=20 >> On Fri, Dec 16, 2011 at 03:49, Tim Chown wrote: >>> Well, there are two questions here. >>>=20 >>> One is whether the WG believes the update as described in = draft-ietf-6man-rfc3484-revise-05 is correct and complete. I have not = seen (yet) any significant technical concerns raised. The last of those = were discussed and (we believe) resolved in Quebec. Are there any more? >>=20 >> It appears that there is general agreement here, with possibly a few >> technical/content nits that probably need to be sorted in a final >> revision, raised by Dave and documented in message: >> https://www.ietf.org/mail-archive/web/ipv6/current/msg14984.html >>=20 >>> The other is whether the WG believes we should publish an update, or = a complete fresh version of RFC3484. This was discussed previously in = the WG and the update path preferred. If a fresh version is now deemed = more appropriate, I am fine to work on that with the other authors if = required. >>=20 >> My understanding is that there is also general agreement here; that >> this should be published as an update (after being re-organized a = bit) >> now, and then followed up with a replace (bis) I-D. As I have >> previously stated; the changes in this update are needed and are >> time-sensitive, the sooner this update can become an RFC the better. >>=20 >>> We just need a decision so we can progress this - it's been so close = to release for a long time. Many of the changes in the update have been = implemented in a number of platforms already. >>=20 >> Agreed, let's get this done! =3D) >>=20 >> Cheers, >> ~Chris >>=20 >> PS - I don't want to step on any toes here, but I'd be happy to take = a >> stab at a revision based on the current feedback if the authors would >> like, I could probably get it done by the end of next week, possibly >> sooner. >>=20 >>> Tim >>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >>=20 >>=20 >> --=20 >> @ChrisGrundemann >> weblog.chrisgrundemann.com >> www.burningwiththebush.com >> www.theIPv6experts.net >> www.coisoc.org >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 >=20 > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 --Apple-Mail-18-653778045-- From brian.e.carpenter@gmail.com Tue Jan 17 18:52:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FAB21F8486 for ; Tue, 17 Jan 2012 18:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.521 X-Spam-Level: X-Spam-Status: No, score=-103.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJCZVFCfAs9k for ; Tue, 17 Jan 2012 18:52:03 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D60C21F86C3 for ; Tue, 17 Jan 2012 18:52:03 -0800 (PST) Received: by ggnr5 with SMTP id r5so4204699ggn.31 for ; Tue, 17 Jan 2012 18:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ps9Is6dlR9/IYNx+RGj/xF1wTXDKlg7bkmdlPuslXJs=; b=gs8Ab5xdDnc/dyI0Q4ljF96UeMxrb6ztBb4Gb7JyHOKlPnaAZ8QZs4NGJizLlr9y3r jhxClI/pMKf+H11JMmacwTz/BS1P9VkGv2PTITl9D/JcyRIIfG9/17pAnsPTiVPhUaEi IWUydMY9oQsCzasKjHFbyJwJEdHhfUEYhwedo= Received: by 10.100.231.4 with SMTP id d4mr4625166anh.37.1326855122785; Tue, 17 Jan 2012 18:52:02 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id u9sm65498545anh.20.2012.01.17.18.51.58 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 18:52:01 -0800 (PST) Message-ID: <4F1633D7.7050709@gmail.com> Date: Wed, 18 Jan 2012 15:52:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Andrews Subject: Re: -06 candidate References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> In-Reply-To: <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , draft-ietf-6man-rfc3484-revise@tools.ietf.org, 6man Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:52:05 -0000 On 2012-01-18 11:26, Mark Andrews wrote: > ULA need to be de-preferenced except for the local ULA prefixes. > > Below is what I use in FreeBSD 8. It keeps local traffic using > fd92:7065:b8e::/48 rather than using the PA address. If you learn > a ULA destination address that is not local YOU DO NOT WANT TO USE > IT by default when you have another choice. Not true if you have a VPN link to a business partner and you want your traffic to that partner to use the ULA, which is routed via the VPN, rather than a GUA that is routed via the Internet. Not true if an enterprise uses multiple ULA prefixes internally for some reason. These cases will need explicit policy table entries if the default is de-pref as you suggest. Brian > > What you do want is for a interface when it learns a ULA address > to add the corresponding /48 prefix with a given precedence and a > unique label to the table if the prefix does not exist. And > appropriate cleaning be done when no more interfaces exist in the > /48. This may require a manual tag on table entries. > > Mark > >> more /etc/ip6addrctl.conf > #Prefix Prec Label > ::1/128 50 0 > ::/0 40 1 > 2002::/16 30 2 > ::/96 20 3 > ::ffff:0.0.0.0/96 35 4 > fd92:7065:b8e::/48 45 5 > fc00::/7 5 6 >> ifconfig nfe0 inet6 > nfe0: flags=8843 metric 0 mtu 1500 > options=82008 > inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 > inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf > inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf From marka@isc.org Tue Jan 17 20:11:55 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7170C21F85E6 for ; Tue, 17 Jan 2012 20:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTAaza+ohiHi for ; Tue, 17 Jan 2012 20:11:55 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EC33221F85E0 for ; Tue, 17 Jan 2012 20:11:54 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id BC678C94E0; Wed, 18 Jan 2012 04:11:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:7034:c5d9:cda5:d5c0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 61425216C6B; Wed, 18 Jan 2012 04:11:44 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 3BC9F1B8B894; Wed, 18 Jan 2012 15:11:42 +1100 (EST) To: Brian E Carpenter From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> <4F1633D7.7050709@gmail.com> Subject: Re: -06 candidate In-reply-to: Your message of "Wed, 18 Jan 2012 15:52:07 +1300." <4F1633D7.7050709@gmail.com> Date: Wed, 18 Jan 2012 15:11:42 +1100 Message-Id: <20120118041142.3BC9F1B8B894@drugs.dv.isc.org> Cc: Tim Chown , 6man Mailing List , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 04:11:55 -0000 In message <4F1633D7.7050709@gmail.com>, Brian E Carpenter writes: > On 2012-01-18 11:26, Mark Andrews wrote: > > ULA need to be de-preferenced except for the local ULA prefixes. > > > > Below is what I use in FreeBSD 8. It keeps local traffic using > > fd92:7065:b8e::/48 rather than using the PA address. If you learn > > a ULA destination address that is not local YOU DO NOT WANT TO USE > > IT by default when you have another choice. > > Not true if you have a VPN link to a business partner and you want > your traffic to that partner to use the ULA, which is routed via > the VPN, rather than a GUA that is routed via the Internet. Which doesn't fall under a *default* policy. You would add the partner's /48 to custom table and distribute it rather than use the default. > Not true if an enterprise uses multiple ULA prefixes internally > for some reason. Again this doesn't fall under a *default* policy. > These cases will need explicit policy table entries if the default > is de-pref as you suggest. And any ULA address that leaks, and they will, will cause back holes to appear, similar to the way broken 6to4 does. Fast retries, similar to HE, will help somewhat but sensible defaults and knowing when to override them work even better. > Brian -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian@innovationslab.net Wed Jan 18 05:57:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C821F87AB for ; Wed, 18 Jan 2012 05:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR+i9W7b7z7m for ; Wed, 18 Jan 2012 05:57:53 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A63AA21F869F for ; Wed, 18 Jan 2012 05:57:53 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6D82F880A4; Wed, 18 Jan 2012 05:57:53 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5A9AB13680E6; Wed, 18 Jan 2012 05:57:51 -0800 (PST) Message-ID: <4F16CFDD.5080904@innovationslab.net> Date: Wed, 18 Jan 2012 08:57:49 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sam Silvester Subject: Re: [Editorial Errata Reported] RFC6434 (3091) References: <20120116232606.377C8B1E007@rfc-editor.org> <4F15BB0C.5040108@innovationslab.net> In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: john.loughney@nokia.com, narten@us.ibm.com, ipv6@ietf.org, bob.hinden@gmail.com, rdroms.ietf@gmail.com, RFC Errata System X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:57:54 -0000 On 1/17/12 4:36 PM, Sam Silvester wrote: > On Wed, Jan 18, 2012 at 4:46 AM, Brian Haberman > wrote: >> >> I am not sure there is a benefit to adding a single adjective to the noted >> sentence. The actual reference is correct, so the reader will be correctly >> directed to the Lightweight MLD specification. >> >> Regards, >> Brian > > Fair enough. > > My understanding was that "Lightweight MLDv2" is the name of the RFC > in the reference, as such shouldn't we be getting it right - > especially in the sense that the name is close enough to MLDv2 and > therefore avoiding confusion would be a good thing? i.e. it's less an > adjective - if we're referring to an RFC, we should do it properly - > especially when there is another, similar and related RFC that is also > being discussed in the same paragraph? > > If only because it made me stop, get a little confused and have to go > back and re-read the section (hence the Errata!) to get it clear in my > mind what was going on. I parsed the sentence differently. I interpreted it as "implement MLDv2 using the guidance provided in RFC...". In other words, I did not interpret "MLDv2" as the title of the referenced RFC. I am curious as to what others think about this. Regards, Brian From narten@us.ibm.com Wed Jan 18 06:17:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA4221F8797 for ; Wed, 18 Jan 2012 06:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8GkTVWjwgUz for ; Wed, 18 Jan 2012 06:17:08 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id A525421F8786 for ; Wed, 18 Jan 2012 06:17:01 -0800 (PST) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 18 Jan 2012 07:17:00 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 18 Jan 2012 07:16:58 -0700 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 9577D19D8026 for ; Wed, 18 Jan 2012 07:16:55 -0700 (MST) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0IEFVKQ100424 for ; Wed, 18 Jan 2012 07:16:57 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0IE4sn4032551 for ; Wed, 18 Jan 2012 07:04:54 -0700 Received: from 127.0.0.1 (sig-9-49-155-174.mts.ibm.com [9.49.155.174]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0IE4reH032393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jan 2012 07:04:54 -0700 Received: from 127.0.0.1 (localhost [127.0.0.1]) by 127.0.0.1 (8.14.5/8.12.5) with ESMTP id q0IE4pES020211; Wed, 18 Jan 2012 09:04:51 -0500 Message-Id: <201201181404.q0IE4pES020211@127.0.0.1> To: Brian Haberman Subject: Re: [Editorial Errata Reported] RFC6434 (3091) In-reply-to: <4F16CFDD.5080904@innovationslab.net> References: <20120116232606.377C8B1E007@rfc-editor.org> <4F15BB0C.5040108@innovationslab.net> <4F16CFDD.5080904@innovationslab.net> Comments: In-reply-to Brian Haberman message dated "Wed, 18 Jan 2012 08:57:49 -0500." Date: Wed, 18 Jan 2012 09:04:51 -0500 From: Thomas Narten X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12011814-7408-0000-0000-000001F9233B Cc: john.loughney@nokia.com, ipv6@ietf.org, bob.hinden@gmail.com, rdroms.ietf@gmail.com, RFC Errata System X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:17:09 -0000 > I am curious as to what others think about this. IMO, we are discussing trivialities, not something rising to the level of needing an errata or worth spending any more of our time on. Thomas From john.loughney@nokia.com Wed Jan 18 06:17:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703EC21F879D for ; Wed, 18 Jan 2012 06:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVeEELguhlBy for ; Wed, 18 Jan 2012 06:17:56 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id AD67921F8786 for ; Wed, 18 Jan 2012 06:17:56 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0IEHqwI009133; Wed, 18 Jan 2012 16:17:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 16:17:52 +0200 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.136]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 15:17:51 +0100 From: To: , Subject: RE: [Editorial Errata Reported] RFC6434 (3091) Thread-Topic: [Editorial Errata Reported] RFC6434 (3091) Thread-Index: AQHM1Kaz5jHSFuDrWkaLxY07y5ZdDZYQzkQAgAA3tYCAARJJgIAAAfeAgAAUVjA= Date: Wed, 18 Jan 2012 14:17:50 +0000 Message-ID: <2129067463716F46AC77A22602E5CB5C02046F30@008-AM1MPN1-017.mgdnok.nokia.com> References: <20120116232606.377C8B1E007@rfc-editor.org> <4F15BB0C.5040108@innovationslab.net> <4F16CFDD.5080904@innovationslab.net> <201201181404.q0IE4pES020211@127.0.0.1> In-Reply-To: <201201181404.q0IE4pES020211@127.0.0.1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Io4Yp9BG4xNs1b6Arva//QSSTk9P+faHsncGfPMAO2PFWiTlUjuwq1UKqtgPSwQaFt7D6TaY5l5/w9LSBSb/9IUfH2N0Lu3IEFlNhi8cE9gjK6HAe5KqL0H+acfeohDs2rcGCpg5F5bPR6fwwjlWhPkoFHyrEPvQD80vls7cJAHWN+iVb/f/YM+zp0nMFi7QnAOpNRmmHaWijBTkSyevYTFLvysK95caDOkrz3GyoZtj x-headerinfofordlp: None x-originating-ip: [10.243.0.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 14:17:52.0229 (UTC) FILETIME=[F6D81950:01CCD5EB] X-Nokia-AV: Clean Cc: bob.hinden@gmail.com, ipv6@ietf.org, rdroms.ietf@gmail.com, rfc-editor@rfc-editor.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:17:57 -0000 I agree with Thomas. -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of ext= Thomas Narten Sent: Wednesday, January 18, 2012 6:05 AM To: Brian Haberman Cc: Loughney John (Nokia-SD/SiliconValley); ipv6@ietf.org; bob.hinden@gmail= .com; rdroms.ietf@gmail.com; RFC Errata System Subject: Re: [Editorial Errata Reported] RFC6434 (3091) > I am curious as to what others think about this. IMO, we are discussing trivialities, not something rising to the level of n= eeding an errata or worth spending any more of our time on. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From tom.taylor.stds@gmail.com Wed Jan 18 07:13:03 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5CF21F8737 for ; Wed, 18 Jan 2012 07:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b0dyetSITBx for ; Wed, 18 Jan 2012 07:13:03 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E180821F8735 for ; Wed, 18 Jan 2012 07:13:02 -0800 (PST) Received: by yenl5 with SMTP id l5so224763yen.31 for ; Wed, 18 Jan 2012 07:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=q1ArnA7+J4Dgcmq/Z/nnw0/0BWynDLVBlE/foJAcMPE=; b=Lf1nX3xmgRrmzodApKo+VNYakK7HGBSbexEjOROij2o3WgmaGLuq9pgFJM6cbhGGWW uqzXIhN1PVUqqR/bNlONmvc0c/V1QxjoqZuGPA+CBDtTIiShdUAIJ2xzb8EHwtx9SWK/ pNYBWKlHM6EgN50i/8aRLbrL+oOWCQwmy8a4Q= Received: by 10.236.155.225 with SMTP id j61mr32268449yhk.43.1326899582564; Wed, 18 Jan 2012 07:13:02 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-170-82.tor.primus.ca. [173.206.170.82]) by mx.google.com with ESMTPS id j16sm70361639anm.9.2012.01.18.07.13.01 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 07:13:02 -0800 (PST) Message-ID: <4F16E17C.9020909@gmail.com> Date: Wed, 18 Jan 2012 10:13:00 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: [Editorial Errata Reported] RFC6434 (3091) References: <20120116232606.377C8B1E007@rfc-editor.org> <4F15BB0C.5040108@innovationslab.net> <4F16CFDD.5080904@innovationslab.net> <201201181404.q0IE4pES020211@127.0.0.1> In-Reply-To: <201201181404.q0IE4pES020211@127.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120118-0, 18/01/2012), Outbound message X-Antivirus-Status: Clean X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 15:13:03 -0000 I on the other hand, as a more naive reader, find the update useful to understanding. On 18/01/2012 9:04 AM, Thomas Narten wrote: >> I am curious as to what others think about this. > > IMO, we are discussing trivialities, not something rising to the level > of needing an errata or worth spending any more of our time on. > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From wwwrun@ietfa.amsl.com Thu Jan 19 11:27:52 2012 Return-Path: X-Original-To: IPv6 Delivered-To: IPv6@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id D613821F85E1; Thu, 19 Jan 2012 11:27:52 -0800 (PST) From: The IESG To: ipv6-chairs@tools.ietf.org, DNS@ietfa.amsl.com, Extensions@ietfa.amsl.com, to@ietfa.amsl.com, Support@ietfa.amsl.com, IPv6@ietfa.amsl.com, Address@ietfa.amsl.com, Aggregation@ietfa.amsl.com, and@ietfa.amsl.com, Renumbering@tools.ietf.org (Expired) Subject: ID Tracker State Update Notice: RFC 2874 Message-Id: <20120119192752.D613821F85E1@ietfa.amsl.com> Date: Thu, 19 Jan 2012 11:27:52 -0800 (PST) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 19:27:53 -0000 'State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=2874&rfc_flag=1 From joelja@bogus.com Sat Jan 21 15:51:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607EA21F84B2 for ; Sat, 21 Jan 2012 15:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWyWb7nh58F4 for ; Sat, 21 Jan 2012 15:51:05 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A373121F849C for ; Sat, 21 Jan 2012 15:50:38 -0800 (PST) Received: from Joels-MacBook-Pro.local (243.sub-166-250-44.myvzw.com [166.250.44.243]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q0LNob0F074001 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 21 Jan 2012 23:50:38 GMT (envelope-from joelja@bogus.com) Message-ID: <4F1B4F47.9030805@bogus.com> Date: Sat, 21 Jan 2012 15:50:31 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: 6man Subject: re: draft-gashinsky-6man-v6nd-enhance-00 comments... Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 21 Jan 2012 23:50:38 +0000 (UTC) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 23:51:06 -0000 we posted a new version of the neighbor discovery enhancement draft with the intention of keeping the discussion of standards track-requiring ehancement to v6nd alive, as we have pushed the operational advice and impletementation recomendations into a v6ops draft now in WGLC that draft is: http://tools.ietf.org/html/draft-ietf-v6ops-v6nd-problems-02 the ehancements draft is: http://tools.ietf.org/html/draft-gashinsky-6man-v6nd-enhance-00 From arifumi@nttv6.net Sun Jan 22 22:38:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8CC21F8605 for ; Sun, 22 Jan 2012 22:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWtvkzHmLzj5 for ; Sun, 22 Jan 2012 22:38:09 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 38CEE21F8604 for ; Sun, 22 Jan 2012 22:38:08 -0800 (PST) Received: from [IPv6:2001:fa8:1010::b81b:55f1:fecf:b5c2] ([IPv6:2001:fa8:1010:0:b81b:55f1:fecf:b5c2]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q0N6ZrVB028520; Mon, 23 Jan 2012 15:35:57 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: ULA macro in the policy table Re: -06 candidate Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> Date: Mon, 23 Jan 2012 15:33:26 +0900 Content-Transfer-Encoding: 7bit Message-Id: <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Tim Chown , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 06:38:10 -0000 Mark, thank you for your comment. As you mention it, it should be less harmful to give the whole ULA block a lower precedence value, if we assume ULA leakages will happen here and there by DNS mis-configurations, address information exchange in P2P applications, and so on. Regarding communication between ULAs, such a network that really wants to make use of multiple ULA blocks should have a way of controlling address selection behavior of their hosts, such as policy table configuration and DNS configuration. The question is whether we can accept the appearance of macro in the policy table. Prefix Precedence Label ::1/128 60 0 :/48 50 1 ::/0 40 2 ::ffff:0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 fc00::/7 5 6 ::/96 1 10 fec0::/10 1 11 3ffe::/16 1 12 I assume the line of will be interpreted as a line or lines of ULA prefix(es) that is attached to interface(s). Another point is that a host has to maintain the ULA line in responses to addition and deletion of the addresses. Regards, On 2012/01/18, at 7:26, Mark Andrews wrote: > > ULA need to be de-preferenced except for the local ULA prefixes. > > Below is what I use in FreeBSD 8. It keeps local traffic using > fd92:7065:b8e::/48 rather than using the PA address. If you learn > a ULA destination address that is not local YOU DO NOT WANT TO USE > IT by default when you have another choice. > > What you do want is for a interface when it learns a ULA address > to add the corresponding /48 prefix with a given precedence and a > unique label to the table if the prefix does not exist. And > appropriate cleaning be done when no more interfaces exist in the > /48. This may require a manual tag on table entries. > > Mark > >> more /etc/ip6addrctl.conf > #Prefix Prec Label > ::1/128 50 0 > ::/0 40 1 > 2002::/16 30 2 > ::/96 20 3 > ::ffff:0.0.0.0/96 35 4 > fd92:7065:b8e::/48 45 5 > fc00::/7 5 6 >> ifconfig nfe0 inet6 > nfe0: flags=8843 metric 0 mtu 1500 > options=82008 > inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 > inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf > inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From marka@isc.org Sun Jan 22 23:10:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2321F8607 for ; Sun, 22 Jan 2012 23:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol1FJz66lldX for ; Sun, 22 Jan 2012 23:10:24 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id E8B1421F85BD for ; Sun, 22 Jan 2012 23:10:23 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 2E14DC9465; Mon, 23 Jan 2012 07:09:50 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:f85b:3165:984b:f09b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 8F585216C6B; Mon, 23 Jan 2012 07:09:49 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9A8DA1BD391A; Mon, 23 Jan 2012 18:09:47 +1100 (EST) To: Arifumi Matsumoto From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net> Subject: Re: ULA macro in the policy table Re: -06 candidate In-reply-to: Your message of "Mon, 23 Jan 2012 15:33:26 +0900." <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net> Date: Mon, 23 Jan 2012 18:09:47 +1100 Message-Id: <20120123070947.9A8DA1BD391A@drugs.dv.isc.org> Cc: 6man Mailing List , Tim Chown , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 07:10:25 -0000 In message <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net>, Arifumi Matsumoto writes: > Mark, > thank you for your comment. > > As you mention it, it should be less harmful to give the whole ULA > block a lower precedence value, if we assume ULA leakages will happen > here and there by DNS mis-configurations, address information exchange > in P2P applications, and so on. > > Regarding communication between ULAs, such a network that really wants > to make use of multiple ULA blocks should have a way of controlling > address selection behavior of their hosts, such as policy table > configuration and DNS configuration. > > The question is whether we can accept the appearance of macro in > the policy table. > > Prefix Precedence Label > ::1/128 60 0 > :/48 50 1 You also want the labels for each ULA/48 to be seperate. :/48 50 # > ::/0 40 2 > ::ffff:0:0/96 30 3 > 2002::/16 20 4 > 2001::/32 10 5 > fc00::/7 5 6 > ::/96 1 10 > fec0::/10 1 11 > 3ffe::/16 1 12 > > I assume the line of will be interpreted as a line > or lines of ULA prefix(es) that is attached to interface(s). > > Another point is that a host has to maintain the ULA line in responses > to addition and deletion of the addresses. > > Regards, > > On 2012/01/18, at 7:26, Mark Andrews wrote: > > > > > ULA need to be de-preferenced except for the local ULA prefixes. > > > > Below is what I use in FreeBSD 8. It keeps local traffic using > > fd92:7065:b8e::/48 rather than using the PA address. If you learn > > a ULA destination address that is not local YOU DO NOT WANT TO USE > > IT by default when you have another choice. > > > > What you do want is for a interface when it learns a ULA address > > to add the corresponding /48 prefix with a given precedence and a > > unique label to the table if the prefix does not exist. And > > appropriate cleaning be done when no more interfaces exist in the > > /48. This may require a manual tag on table entries. > > > > Mark > > > >> more /etc/ip6addrctl.conf > > #Prefix Prec Label > > ::1/128 50 0 > > ::/0 40 1 > > 2002::/16 30 2 > > ::/96 20 3 > > ::ffff:0.0.0.0/96 35 4 > > fd92:7065:b8e::/48 45 5 > > fc00::/7 5 6 > >> ifconfig nfe0 inet6 > > nfe0: flags=8843 metric 0 mtu 1500 > > options=82008 > > inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5 > > inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf > > inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf > >> > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > -- > Arifumi Matsumoto > NGN System Architecture Project > NTT Service Integration Laboratories > E-mail: arifumi@nttv6.net > TEL +81-422-59-3334 FAX +81-422-59-6364 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From brian.e.carpenter@gmail.com Mon Jan 23 17:18:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFF421F8615 for ; Mon, 23 Jan 2012 17:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.924 X-Spam-Level: X-Spam-Status: No, score=-102.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie5+j0ckM8PS for ; Mon, 23 Jan 2012 17:18:18 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA5821F8605 for ; Mon, 23 Jan 2012 17:18:18 -0800 (PST) Received: by ggnq4 with SMTP id q4so1237684ggn.31 for ; Mon, 23 Jan 2012 17:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GG1STyLXDx/9jtjppK/9kXup54kZrbpFkr4uAQHYbPs=; b=fCaNHhxSNIBFIG9aC7XhCOi9Z9xow89J7YVlomSduxVEZd9S7e1x7LPhTAst8XuTF3 /wyfuyD0yg9usZabsqnnTYUeK8CTnfiH5cycUDOtUjK2hszbieZHTiEsKkKDhCDm/d8J tJNctnmDns3qmi+ZNPRqArSJ4ZmJshWPU3gx8= Received: by 10.100.237.16 with SMTP id k16mr4519921anh.85.1327367897846; Mon, 23 Jan 2012 17:18:17 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id b12sm3961099yhj.4.2012.01.23.17.18.15 (version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 17:18:16 -0800 (PST) Message-ID: <4F1E06DF.2090307@gmail.com> Date: Tue, 24 Jan 2012 14:18:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> In-Reply-To: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:18:18 -0000 Hi, I really don't like the use of the counter in Fernando's proposed algorithm: Flow Label = counter + F(Source Address, Destination Address, Secret Key) It seems to me that it introduces significant predictability for a malicious observer of the packets leaving a given source. Effectively the equivalent algorithm in RFC 6437 is Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key) which is less predictable, even if the port number is not randomized. I'll have more to say once a current investigation of algorithms by a student is finished. Regards Brian Carpenter From fgont@si6networks.com Mon Jan 23 18:49:40 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5021F85B8 for ; Mon, 23 Jan 2012 18:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjdYTleqr8Lp for ; Mon, 23 Jan 2012 18:49:40 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBC421F85AF for ; Mon, 23 Jan 2012 18:49:40 -0800 (PST) Received: from [190.48.228.56] (helo=[192.168.0.45]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RpWRy-0004ju-Mu; Tue, 24 Jan 2012 03:49:35 +0100 Message-ID: <4F1E1C38.1070901@si6networks.com> Date: Mon, 23 Jan 2012 23:49:28 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> In-Reply-To: <4F1E06DF.2090307@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 02:49:40 -0000 Hi, Brian, On 01/23/2012 10:18 PM, Brian E Carpenter wrote: > I really don't like the use of the counter in Fernando's proposed algorithm: > > Flow Label = counter + F(Source Address, Destination Address, Secret Key) > > It seems to me that it introduces significant predictability for a malicious > observer of the packets leaving a given source. As noted off-list, I personally think that rather than proposing a single algorithm, we should describe a set of algorithms, a la RFC 6056 -- as there a number of tradeoffs- > Effectively the equivalent algorithm in RFC 6437 is > > Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key) > > which is less predictable, even if the port number is not randomized. If the attacker can predict the algorithm in draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses of the two endpoints, and the secret key. So I don't see what'd be the real improvement of this variant. That said, it also seems technically incorrect: If you expect the resulting (src ip, dst ip, flow label) to be unique, then introducing the port numbers in F() could lead to unnecessary collisions. Yes, now that the requirement of uniqueness has been relaxed, collisions are less important... but I don't see what's the "gain" of the modified expression you suggest above. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Mon Jan 23 19:04:31 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124DD21F862F for ; Mon, 23 Jan 2012 19:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSJiPbK1hL9s for ; Mon, 23 Jan 2012 19:04:30 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9202E21F862D for ; Mon, 23 Jan 2012 19:04:30 -0800 (PST) Received: by ghbg16 with SMTP id g16so1259775ghb.31 for ; Mon, 23 Jan 2012 19:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1uvpfnty+Z0CuzCXXmnzxZz6oUcejK6vRgNo2hbrrGU=; b=cBjpDHMiqYvmKmR05ZEyiYH0TpQ0puIClo9DxA/XLrW0pIAGOfJS6fYeqvRyit+JtP 16iXTJfcSd3vqw6gk7qnmEbamAgAiJoUT/umRxdhyA/1/oPzGT6bBRKR7Qd62zPPSSQO W56VdcWXSztV2BsNe7sjoa2bo+RvsreRZZToM= Received: by 10.236.124.172 with SMTP id x32mr15148788yhh.19.1327374270186; Mon, 23 Jan 2012 19:04:30 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id h20sm40708222ang.7.2012.01.23.19.04.27 (version=SSLv3 cipher=OTHER); Mon, 23 Jan 2012 19:04:29 -0800 (PST) Message-ID: <4F1E1FC3.2000206@gmail.com> Date: Tue, 24 Jan 2012 16:04:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> In-Reply-To: <4F1E1C38.1070901@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 03:04:31 -0000 On 2012-01-24 15:49, Fernando Gont wrote: > Hi, Brian, > > On 01/23/2012 10:18 PM, Brian E Carpenter wrote: >> I really don't like the use of the counter in Fernando's proposed algorithm: >> >> Flow Label = counter + F(Source Address, Destination Address, Secret Key) >> >> It seems to me that it introduces significant predictability for a malicious >> observer of the packets leaving a given source. > > As noted off-list, I personally think that rather than proposing a > single algorithm, we should describe a set of algorithms, a la RFC 6056 > -- as there a number of tradeoffs- > > >> Effectively the equivalent algorithm in RFC 6437 is >> >> Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key) >> >> which is less predictable, even if the port number is not randomized. > > If the attacker can predict the algorithm in > draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses > of the two endpoints, and the secret key. So I don't see what'd be the > real improvement of this variant. With your proposal, after observing label N, you can (with reasonable probability) predict label N+1; you don't need this to be 100% accurate to cause trouble. > > That said, it also seems technically incorrect: If you expect the > resulting (src ip, dst ip, flow label) to be unique, then introducing > the port numbers in F() could lead to unnecessary collisions. Sure, as noted in the new RFC: a statistically small rate of collisions does not significantly bias load sharing. > > Yes, now that the requirement of uniqueness has been relaxed, collisions > are less important... but I don't see what's the "gain" of the modified > expression you suggest above. That label 4502 will essentially never be followed by label 4503, which your method explictly allows (your Table 1). Include the counter in the input to the hash function and this problem disappears. Regards Brian From fgont@si6networks.com Mon Jan 23 20:17:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD9921F860F for ; Mon, 23 Jan 2012 20:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DCWIMVh5umB for ; Mon, 23 Jan 2012 20:17:22 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6961B21F85CE for ; Mon, 23 Jan 2012 20:17:22 -0800 (PST) Received: from [190.48.228.56] (helo=[192.168.0.45]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RpXot-00068s-Mx; Tue, 24 Jan 2012 05:17:21 +0100 Message-ID: <4F1E30C4.8020408@si6networks.com> Date: Tue, 24 Jan 2012 01:17:08 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> In-Reply-To: <4F1E1FC3.2000206@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 04:17:23 -0000 On 01/24/2012 12:04 AM, Brian E Carpenter wrote: >>> Effectively the equivalent algorithm in RFC 6437 is >>> >>> Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key) >>> >>> which is less predictable, even if the port number is not randomized. >> >> If the attacker can predict the algorithm in >> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses >> of the two endpoints, and the secret key. So I don't see what'd be the >> real improvement of this variant. > > With your proposal, after observing label N, you can (with reasonable probability) > predict label N+1; you don't need this to be 100% accurate to cause trouble. If the attacker can *observe* labels, why would he bother to "guess" them? >> Yes, now that the requirement of uniqueness has been relaxed, collisions >> are less important... but I don't see what's the "gain" of the modified >> expression you suggest above. > > That label 4502 will essentially never be followed by label 4503, > which your method explictly allows (your Table 1). Include the counter in > the input to the hash function and this problem disappears. Well, one should clearly state the threat model: If you're thinking about off-path attackers, then the fact that flow labels corresponding to the same set (src IP, dst IP) will be incremental is irrelevant (the attacker knows that the Flow-IDs are a monotonically-increasing sequence, but does not know where that sequence is). If the threat model is that we're concerned about on-path attacker, then: game over: the attacker will always know the FlowLabel values, regardless of the algorithm that we use. That said, and as noted above, it is interesting to offer alternatives. For example, if you implement the hash-based approach described in my I-D, the first flow label is "expensive", but the rest are really cheap: e.g., just add the counter to the value of F() that you have recorded in the destinations cache. OTOH, randomizing every FlowLabel might be more expensive. I personally think that rather than enforcing a single algorithm, we should offer a set of possible algorithms, and discuss the tradeoffs -- after all, not all implementations need to agree on the same algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Tue Jan 24 12:18:41 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406C21F84D6 for ; Tue, 24 Jan 2012 12:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.042 X-Spam-Level: X-Spam-Status: No, score=-102.042 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dP0cS0efcvmV for ; Tue, 24 Jan 2012 12:18:40 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A269821F84D5 for ; Tue, 24 Jan 2012 12:18:40 -0800 (PST) Received: by iagf6 with SMTP id f6so6381750iag.31 for ; Tue, 24 Jan 2012 12:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nULD3NOmnRew/08qnmVyXKJAhG10JfvBuT0WwkJ0/40=; b=HcYN0tBI5mne5KZN7YsMA77kQ2nAl1QBSsqrNoP0Y8jjnyTq9DnzmtcMuSmQecSWXG SyGKoRLshTh/tpmu87OMa2G8QoxD+RWvpG31uM7TNKr9Ut5viQ+WZkLvg4lXtMKm40zc SRjf+B2SRAlE2OZd0S0ViXxMjse/63VE8EEX8= Received: by 10.50.216.201 with SMTP id os9mr4951030igc.22.1327436320278; Tue, 24 Jan 2012 12:18:40 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id gd2sm24137069igc.1.2012.01.24.12.18.37 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 12:18:39 -0800 (PST) Message-ID: <4F1F121D.40409@gmail.com> Date: Wed, 25 Jan 2012 09:18:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> In-Reply-To: <4F1E30C4.8020408@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:18:41 -0000 On 2012-01-24 17:17, Fernando Gont wrote: > On 01/24/2012 12:04 AM, Brian E Carpenter wrote: > >>>> Effectively the equivalent algorithm in RFC 6437 is >>>> >>>> Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key) >>>> >>>> which is less predictable, even if the port number is not randomized. >>> If the attacker can predict the algorithm in >>> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses >>> of the two endpoints, and the secret key. So I don't see what'd be the >>> real improvement of this variant. >> With your proposal, after observing label N, you can (with reasonable probability) >> predict label N+1; you don't need this to be 100% accurate to cause trouble. > > If the attacker can *observe* labels, why would he bother to "guess" them? So that s/he can generate plausible bogons as part of a DOS attack. It seems to me that predictability of the flow label is similar to predictability of port numbers in that respect. >>> Yes, now that the requirement of uniqueness has been relaxed, collisions >>> are less important... but I don't see what's the "gain" of the modified >>> expression you suggest above. >> That label 4502 will essentially never be followed by label 4503, >> which your method explictly allows (your Table 1). Include the counter in >> the input to the hash function and this problem disappears. > > Well, one should clearly state the threat model: > If you're thinking about off-path attackers, then the fact that flow > labels corresponding to the same set (src IP, dst IP) will be > incremental is irrelevant (the attacker knows that the Flow-IDs are a > monotonically-increasing sequence, but does not know where that sequence > is). If you are trying to confuse a load balancing algorithm, being able to predict the next new SYN packet, even only with partial success, might be a useful thing. Since all major content providers run load balancers, attacks on load balancing algorithms are an important concern. If you can bias a load balancer to (almost) always pick the same server, the content provider will not be happy. (Note: I am not suggesting that existing load balancers are open to such an attack, but we don't want the flow label to make things worse.) > > If the threat model is that we're concerned about on-path attacker, > then: game over: the attacker will always know the FlowLabel values, > regardless of the algorithm that we use. Indeed. > That said, and as noted above, it is interesting to offer alternatives. > For example, if you implement the hash-based approach described in my > I-D, the first flow label is "expensive", but the rest are really cheap: > e.g., just add the counter to the value of F() that you have recorded in > the destinations cache. OTOH, randomizing every FlowLabel might be more > expensive. That depends on how much extra you pay for holding state in the destinations cache. A stateless algorithm avoids that. > I personally think that rather than enforcing a single algorithm, we > should offer a set of possible algorithms, and discuss the tradeoffs -- > after all, not all implementations need to agree on the same algorithm. Absolutely; that's why RFC 6437 does not specify an algorithm. Brian From fgont@si6networks.com Tue Jan 24 13:02:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAADD21F8533 for ; Tue, 24 Jan 2012 13:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLLD2H1yJEcb for ; Tue, 24 Jan 2012 13:02:45 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id ADC1221F852B for ; Tue, 24 Jan 2012 13:02:44 -0800 (PST) Received: from [190.48.247.231] (helo=[10.42.43.100]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RpnVp-0003lc-MQ; Tue, 24 Jan 2012 22:02:43 +0100 Message-ID: <4F1F1C64.5010008@si6networks.com> Date: Tue, 24 Jan 2012 18:02:28 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> In-Reply-To: <4F1F121D.40409@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:02:46 -0000 Hi, Brian, On 01/24/2012 05:18 PM, Brian E Carpenter wrote: >>>>> which is less predictable, even if the port number is not randomized. >>>> If the attacker can predict the algorithm in >>>> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses >>>> of the two endpoints, and the secret key. So I don't see what'd be the >>>> real improvement of this variant. >>> With your proposal, after observing label N, you can (with reasonable probability) >>> predict label N+1; you don't need this to be 100% accurate to cause trouble. >> >> If the attacker can *observe* labels, why would he bother to "guess" them? > > So that s/he can generate plausible bogons as part of a DOS attack. It seems > to me that predictability of the flow label is similar to predictability > of port numbers in that respect. Let me rephrase with two questions: a) If an attacker is off-path, how can he "attack" the algorithm proposed in "draft-gont-6man-flowlabel-security-02.txt"? b) If an attacker is on-path how does any algorithm prevent the attacker from *knowing* which FlowLabels he should forge? >> Well, one should clearly state the threat model: >> If you're thinking about off-path attackers, then the fact that flow >> labels corresponding to the same set (src IP, dst IP) will be >> incremental is irrelevant (the attacker knows that the Flow-IDs are a >> monotonically-increasing sequence, but does not know where that sequence >> is). > > If you are trying to confuse a load balancing algorithm, being able to > predict the next new SYN packet, even only with partial success, > might be a useful thing. How could you possible predict, being an off-path attacker, the next FlowLabel? > Since all major content providers run load > balancers, attacks on load balancing algorithms are an important > concern. If you can bias a load balancer to (almost) always pick > the same server, the content provider will not be happy. My understanding is that FlowLabels are expected to be used as I-Ds for flows, and have no internal semantics. -- it's not that forging a specific value will make packets always go through the same set of routers. > (Note: I am not suggesting that existing load balancers are open > to such an attack, but we don't want the flow label to make things > worse.) How worse would the approach in "draft-gont-6man-flowlabel-security-02.txt" for FlowLabels when e.g. Linux uses the same approach for port numbers? >> That said, and as noted above, it is interesting to offer alternatives. >> For example, if you implement the hash-based approach described in my >> I-D, the first flow label is "expensive", but the rest are really cheap: >> e.g., just add the counter to the value of F() that you have recorded in >> the destinations cache. OTOH, randomizing every FlowLabel might be more >> expensive. > > That depends on how much extra you pay for holding state in the destinations > cache. A stateless algorithm avoids that. The destinations cache is already there. So a few bytes per entry does not seem to be a big deal. -- and if it is, then you'd probably be concerned about having the Destinations Cache in the first place.... >> I personally think that rather than enforcing a single algorithm, we >> should offer a set of possible algorithms, and discuss the tradeoffs -- >> after all, not all implementations need to agree on the same algorithm. > > Absolutely; that's why RFC 6437 does not specify an algorithm. I'm fine with not describing any algorithms in the base expect. But I do think that something along the lines of RFC 6056 is needed -- everytime something like that was misswing, people got it wrong. Thing about IP ID, TCP port numbers, etc., etc. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Tue Jan 24 18:40:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F1E21F8574 for ; Tue, 24 Jan 2012 18:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.296 X-Spam-Level: X-Spam-Status: No, score=-102.296 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_00=-2.599, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiAOwSyhHsPB for ; Tue, 24 Jan 2012 18:39:59 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 932A621F849D for ; Tue, 24 Jan 2012 18:39:59 -0800 (PST) Received: by ghbg16 with SMTP id g16so1900556ghb.31 for ; Tue, 24 Jan 2012 18:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G2x38gdgGNCiEWiIoCsJpGnujcmP1ZzfkZnOL82Zjqc=; b=SdJRxWaVNvnZunUxleLLd32X7X5b9gBPUCyRQ3DK86wvUFS800ksJ1to43r0tG0ZC9 Rg2jx9OHz3//vL1Tz1vnwW97Km7l2+2+cVzs5N8qWb7dsgZh4jYgehsk2oZ4/KYnLL+y hnvxlSJx0yPRNgyhmJgTGSNKtbdxuwGBbkCJk= Received: by 10.236.175.164 with SMTP id z24mr21802354yhl.84.1327459199162; Tue, 24 Jan 2012 18:39:59 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id 9sm50377139ans.15.2012.01.24.18.39.56 (version=SSLv3 cipher=OTHER); Tue, 24 Jan 2012 18:39:58 -0800 (PST) Message-ID: <4F1F6B79.7070008@gmail.com> Date: Wed, 25 Jan 2012 15:39:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> In-Reply-To: <4F1F1C64.5010008@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 02:40:00 -0000 On 2012-01-25 10:02, Fernando Gont wrote: > Hi, Brian, > > On 01/24/2012 05:18 PM, Brian E Carpenter wrote: >>>>>> which is less predictable, even if the port number is not randomized. >>>>> If the attacker can predict the algorithm in >>>>> draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses >>>>> of the two endpoints, and the secret key. So I don't see what'd be the >>>>> real improvement of this variant. >>>> With your proposal, after observing label N, you can (with reasonable probability) >>>> predict label N+1; you don't need this to be 100% accurate to cause trouble. >>> If the attacker can *observe* labels, why would he bother to "guess" them? >> So that s/he can generate plausible bogons as part of a DOS attack. It seems >> to me that predictability of the flow label is similar to predictability >> of port numbers in that respect. > > Let me rephrase with two questions: > > a) If an attacker is off-path, how can he "attack" the algorithm > proposed in "draft-gont-6man-flowlabel-security-02.txt"? OK, I mean an attacker who is able to observe the traffic but not perform MITM modifications. Some people call that off-path... > > b) If an attacker is on-path how does any algorithm prevent the attacker > from *knowing* which FlowLabels he should forge? Obviously for an established flow, you can inject forged packets that appear to belong to that flow; we can never prevent this. But if you can predict the flow label for *future* flows, you can forge and inject SYN packets before the real user ever starts the flow. Since a large part of today's forged traffic seems to consist of SYN packets, this seems like a sensitive target. > >>> Well, one should clearly state the threat model: >>> If you're thinking about off-path attackers, then the fact that flow >>> labels corresponding to the same set (src IP, dst IP) will be >>> incremental is irrelevant (the attacker knows that the Flow-IDs are a >>> monotonically-increasing sequence, but does not know where that sequence >>> is). >> If you are trying to confuse a load balancing algorithm, being able to >> predict the next new SYN packet, even only with partial success, >> might be a useful thing. > > How could you possible predict, being an off-path attacker, the next > FlowLabel? Yes, you must be able to passively observe the previous traffic. > > >> Since all major content providers run load >> balancers, attacks on load balancing algorithms are an important >> concern. If you can bias a load balancer to (almost) always pick >> the same server, the content provider will not be happy. > > My understanding is that FlowLabels are expected to be used as I-Ds for > flows, and have no internal semantics. -- it's not that forging a > specific value will make packets always go through the same set of routers. If the label is used in a load balancer, it *might* do exactly that. It isn't certain (see draft-carpenter-v6ops-label-balance-01.txt). >> (Note: I am not suggesting that existing load balancers are open >> to such an attack, but we don't want the flow label to make things >> worse.) > > How worse would the approach in > "draft-gont-6man-flowlabel-security-02.txt" for FlowLabels when e.g. > Linux uses the same approach for port numbers? I thought we were trying to randomise port numbers for exactly that reason; it seems to me that any form of regularity in the numbers is asking for trouble, even if we don't have an exact attack model. >>> That said, and as noted above, it is interesting to offer alternatives. >>> For example, if you implement the hash-based approach described in my >>> I-D, the first flow label is "expensive", but the rest are really cheap: >>> e.g., just add the counter to the value of F() that you have recorded in >>> the destinations cache. OTOH, randomizing every FlowLabel might be more >>> expensive. >> That depends on how much extra you pay for holding state in the destinations >> cache. A stateless algorithm avoids that. > > The destinations cache is already there. So a few bytes per entry does > not seem to be a big deal. -- and if it is, then you'd probably be > concerned about having the Destinations Cache in the first place.... It's an engineering trade-off, certainly. My taste is always to avoid extra state, however. >>> I personally think that rather than enforcing a single algorithm, we >>> should offer a set of possible algorithms, and discuss the tradeoffs -- >>> after all, not all implementations need to agree on the same algorithm. >> Absolutely; that's why RFC 6437 does not specify an algorithm. > > I'm fine with not describing any algorithms in the base expect. But I do > think that something along the lines of RFC 6056 is needed -- everytime > something like that was misswing, people got it wrong. Thing about IP > ID, TCP port numbers, etc., etc. Yes, but maybe we need a little experience first. That's why I have a student playing with the largest IPv6 traces we've managed to get hold of. Brian From arifumi@nttv6.net Tue Jan 24 18:40:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B1921F85C4 for ; Tue, 24 Jan 2012 18:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE+yA-Px25yl for ; Tue, 24 Jan 2012 18:40:21 -0800 (PST) Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB521F849D for ; Tue, 24 Jan 2012 18:40:17 -0800 (PST) Received: from radiko.smartstream.ne.jp (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.5/8.14.4) with ESMTP id q0P2cDrR046629; Wed, 25 Jan 2012 11:38:13 +0900 (JST) (envelope-from arifumi@nttv6.net) Subject: Re: ULA macro in the policy table Re: -06 candidate Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arifumi Matsumoto In-Reply-To: <20120123070947.9A8DA1BD391A@drugs.dv.isc.org> Date: Wed, 25 Jan 2012 11:35:45 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <120E3724-7356-45F1-B70C-0B3081D8EDCB@nttv6.net> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net> <20120123070947.9A8DA1BD391A@drugs.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.1084) Cc: 6man Mailing List , Tim Chown , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 02:40:22 -0000 Hi, On 2012/01/23, at 16:09, Mark Andrews wrote: >=20 > In message <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net>, Arifumi = Matsumoto writes: >> Mark, >> thank you for your comment. >>=20 >> As you mention it, it should be less harmful to give the whole ULA >> block a lower precedence value, if we assume ULA leakages will happen >> here and there by DNS mis-configurations, address information = exchange >> in P2P applications, and so on. >>=20 >> Regarding communication between ULAs, such a network that really = wants >> to make use of multiple ULA blocks should have a way of controlling >> address selection behavior of their hosts, such as policy table >> configuration and DNS configuration. >>=20 >> The question is whether we can accept the appearance of macro in >> the policy table. >>=20 >> Prefix Precedence Label >> ::1/128 60 0 >> :/48 50 1 >=20 > You also want the labels for each ULA/48 to be seperate. >=20 > :/48 50 # Do we need to have different labels for ULAs ? If ULAs are assigned to a host, the host can choose an appropriate source ULA address because of the longest match rule. >=20 >> ::/0 40 2 >> ::ffff:0:0/96 30 3 >> 2002::/16 20 4 >> 2001::/32 10 5 >> fc00::/7 5 6 >> ::/96 1 10 >> fec0::/10 1 11 >> 3ffe::/16 1 12 >>=20 >> I assume the line of will be interpreted as a line >> or lines of ULA prefix(es) that is attached to interface(s). >>=20 >> Another point is that a host has to maintain the ULA line in = responses >> to addition and deletion of the addresses. Another possibility is just the de-pref of the whole ULA block. Prefix Precedence Label ::1/128 60 0 ::/0 40 2 ::ffff:0:0/96 30 3 2002::/16 20 4 2001::/32 10 5 fc00::/7 5 6 ::/96 1 10 fec0::/10 1 11 3ffe::/16 1 12 In this case, the problem Mark pointed out will not happen, but ULA will not be preferred over IPv4 and IPv6 global addresses. Do we really prefer ULA over these addresses ? >> On 2012/01/18, at 7:26, Mark Andrews wrote: >>=20 >>>=20 >>> ULA need to be de-preferenced except for the local ULA prefixes. >>>=20 >>> Below is what I use in FreeBSD 8. It keeps local traffic using >>> fd92:7065:b8e::/48 rather than using the PA address. If you learn >>> a ULA destination address that is not local YOU DO NOT WANT TO USE >>> IT by default when you have another choice. >>>=20 >>> What you do want is for a interface when it learns a ULA address >>> to add the corresponding /48 prefix with a given precedence and a >>> unique label to the table if the prefix does not exist. And >>> appropriate cleaning be done when no more interfaces exist in the >>> /48. This may require a manual tag on table entries. >>>=20 >>> Mark >>>=20 >>>> more /etc/ip6addrctl.conf=20 >>> #Prefix Prec Label =20 >>> ::1/128 50 0 >>> ::/0 40 1 =20 >>> 2002::/16 30 2 =20 >>> ::/96 20 3 =20 >>> ::ffff:0.0.0.0/96 35 4 =20 >>> fd92:7065:b8e::/48 45 5=20 >>> fc00::/7 5 6 >>>> ifconfig nfe0 inet6 >>> nfe0: flags=3D8843 metric 0 = mtu 1500 >>> options=3D82008 >>> inet6 fe80::218:f3ff:feba:9a37%nfe0 prefixlen 64 scopeid 0x5=20 >>> inet6 fd92:7065:b8e:0:218:f3ff:feba:9a37 prefixlen 64 autoconf=20= >>> inet6 2001:470:1f00:820:218:f3ff:feba:9a37 prefixlen 64 autoconf=20= >>>>=20 >>> --=20 >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >>=20 >>=20 >> -- >> Arifumi Matsumoto >> NGN System Architecture Project >> NTT Service Integration Laboratories >> E-mail: arifumi@nttv6.net >> TEL +81-422-59-3334 FAX +81-422-59-6364 >>=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Arifumi Matsumoto NGN System Architecture Project NTT Service Integration Laboratories E-mail: arifumi@nttv6.net TEL +81-422-59-3334 FAX +81-422-59-6364 From marka@isc.org Tue Jan 24 18:54:37 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623E211E8088 for ; Tue, 24 Jan 2012 18:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrDFKU113LAO for ; Tue, 24 Jan 2012 18:54:36 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AD8FF11E8086 for ; Tue, 24 Jan 2012 18:54:36 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id A4372C94CA; Wed, 25 Jan 2012 02:54:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:98d1:3a9e:5fb3:f4e5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 13A48216C6B; Wed, 25 Jan 2012 02:54:23 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1CAA01BF7631; Wed, 25 Jan 2012 13:54:20 +1100 (EST) To: Arifumi Matsumoto From: Mark Andrews References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <0D0150C3-9E05-4839-ACF1-0E7196420D2F@ecs.soton.ac.uk> <6DDA8D20-8D10-4B6E-B101-9812FD83B781@nttv6.net> <20120117222653.99F9C1B88A6D@drugs.dv.isc.org> <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net> <20120123070947.9A8DA1BD391A@drugs.dv.isc.org> <120E3724-7356-45F1-B70C-0B3081D8EDCB@nttv6.net> Subject: Re: ULA macro in the policy table Re: -06 candidate In-reply-to: Your message of "Wed, 25 Jan 2012 11:35:45 +0900." <120E3724-7356-45F1-B70C-0B3081D8EDCB@nttv6.net> Date: Wed, 25 Jan 2012 13:54:20 +1100 Message-Id: <20120125025420.1CAA01BF7631@drugs.dv.isc.org> Cc: Tim Chown , 6man Mailing List , draft-ietf-6man-rfc3484-revise@tools.ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 02:54:37 -0000 In message <120E3724-7356-45F1-B70C-0B3081D8EDCB@nttv6.net>, Arifumi Matsumoto writes: > Hi, > > On 2012/01/23, at 16:09, Mark Andrews wrote: > > > > > In message <43F32BAA-C3CB-4214-BCE7-B1CD75EC59FC@nttv6.net>, Arifumi Matsum > oto writes: > >> Mark, > >> thank you for your comment. > >> > >> As you mention it, it should be less harmful to give the whole ULA > >> block a lower precedence value, if we assume ULA leakages will happen > >> here and there by DNS mis-configurations, address information exchange > >> in P2P applications, and so on. > >> > >> Regarding communication between ULAs, such a network that really wants > >> to make use of multiple ULA blocks should have a way of controlling > >> address selection behavior of their hosts, such as policy table > >> configuration and DNS configuration. > >> > >> The question is whether we can accept the appearance of macro in > >> the policy table. > >> > >> Prefix Precedence Label > >> ::1/128 60 0 > >> :/48 50 1 > > > > You also want the labels for each ULA/48 to be seperate. > > > > :/48 50 # > > Do we need to have different labels for ULAs ? > > If ULAs are assigned to a host, the host can choose an appropriate > source ULA address because of the longest match rule. That may be enough. > >> ::/0 40 2 > >> ::ffff:0:0/96 30 3 > >> 2002::/16 20 4 > >> 2001::/32 10 5 > >> fc00::/7 5 6 > >> ::/96 1 10 > >> fec0::/10 1 11 > >> 3ffe::/16 1 12 > >> > >> I assume the line of will be interpreted as a line > >> or lines of ULA prefix(es) that is attached to interface(s). > >> > >> Another point is that a host has to maintain the ULA line in responses > >> to addition and deletion of the addresses. > > Another possibility is just the de-pref of the whole ULA block. > > Prefix Precedence Label > ::1/128 60 0 > ::/0 40 2 > ::ffff:0:0/96 30 3 > 2002::/16 20 4 > 2001::/32 10 5 > fc00::/7 5 6 > ::/96 1 10 > fec0::/10 1 11 > 3ffe::/16 1 12 > > In this case, the problem Mark pointed out will not happen, but > ULA will not be preferred over IPv4 and IPv6 global addresses. > Do we really prefer ULA over these addresses ? Yes. Think Homenet where you want *internal* connections to use ULA rather than PA addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From simon.perreault@viagenie.ca Wed Jan 25 05:23:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2F821F864F for ; Wed, 25 Jan 2012 05:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8Uz972I9Evw for ; Wed, 25 Jan 2012 05:23:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by ietfa.amsl.com (Postfix) with ESMTP id D530F21F864C for ; Wed, 25 Jan 2012 05:23:46 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:14dd:682a:672b:38e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 30F8D21F48 for ; Wed, 25 Jan 2012 08:23:16 -0500 (EST) Message-ID: <4F200243.3040106@viagenie.ca> Date: Wed, 25 Jan 2012 08:23:15 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments References: <4F148730.6030308@innovationslab.net> In-Reply-To: <4F148730.6030308@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:23:47 -0000 On 2012-01-16 15:23, Brian Haberman wrote: > This is a consensus call on adopting: > > Title : Processing of IPv6 "atomic" fragments > Author(s) : Fernando Gont > Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt > Pages : 12 > Date : 2011-12-15 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on January 31, 2012. I support adoption of this document as a WG item. An implementation has been committed yesterday to OpenBSD's IPv6 stack: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet6/frag6.c#rev1.42 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fgont@si6networks.com Wed Jan 25 05:25:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4621F86C1 for ; Wed, 25 Jan 2012 05:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.404 X-Spam-Level: X-Spam-Status: No, score=-0.404 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XweiYEI0Vssu for ; Wed, 25 Jan 2012 05:25:53 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id EBEBF21F86BB for ; Wed, 25 Jan 2012 05:25:52 -0800 (PST) Received: from [190.48.247.231] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rq2rG-0003Ct-KX; Wed, 25 Jan 2012 14:25:51 +0100 Message-ID: <4F1FD701.9050402@si6networks.com> Date: Wed, 25 Jan 2012 07:18:41 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> In-Reply-To: <4F1F6B79.7070008@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:25:54 -0000 On 01/24/2012 11:39 PM, Brian E Carpenter wrote: >>>> If the attacker can *observe* labels, why would he bother to "guess" them? >>> So that s/he can generate plausible bogons as part of a DOS attack. It seems >>> to me that predictability of the flow label is similar to predictability >>> of port numbers in that respect. >> >> Let me rephrase with two questions: >> >> a) If an attacker is off-path, how can he "attack" the algorithm >> proposed in "draft-gont-6man-flowlabel-security-02.txt"? > > OK, I mean an attacker who is able to observe the traffic but not > perform MITM modifications. Some people call that off-path... Well, the attacker *is* on the path if he can observe traffic. That said, if the attacker is able to observe traffic, then game over. Whether we use random FlowLabels or predictable FlowLabels is the same: the attacker is not going to waste his time "guessing" when he can learn the labels by listening to traffic. >> b) If an attacker is on-path how does any algorithm prevent the attacker >> from *knowing* which FlowLabels he should forge? > > Obviously for an established flow, you can inject forged packets that > appear to belong to that flow; we can never prevent this. But if you > can predict the flow label for *future* flows, you can forge and > inject SYN packets before the real user ever starts the flow. Since > a large part of today's forged traffic seems to consist of SYN packets, > this seems like a sensitive target. Since FlowLabels do not carry any specific semantics, I cannot see how "forge and inject before..." would be any worse than firing those packets once the flow has already been established. That aside, as noted above, the attacker could only predict flowlabels if he is on-path. And if the attacker is on-path, game over. >> How worse would the approach in >> "draft-gont-6man-flowlabel-security-02.txt" for FlowLabels when e.g. >> Linux uses the same approach for port numbers? > > I thought we were trying to randomise port numbers for exactly > that reason; it seems to me that any form of regularity in the > numbers is asking for trouble, even if we don't have an exact > attack model. As noted in the port randomization RFC, the goal is that an off-path attacker can not predict values. In particular, if we start imposing requirements such as "we must minimize the probability of FL reuse", etc., then that's certainly asking against randomness at the same time. In the case of port randomization, the port selection algorithm has two goals: * selecting port numbers such that they are not predictable by an off-path attacker * minimizing the port reuse frequency. As a result, a hash based approach can tackles the two of them. An anecdote: While working on the port randomization stuff, a guy from vendor X argued that he'd not implement the hash-based algorithm because one of his customers was running a small app to measure the "randomization quality" of their port selection algorithm. -- Clearly, they were missing the point (and we noted that at the time): what we wanted was the port numbers to be difficult to guess by *off-path* attackers. If the attacker was on the other endpoint of the connection, he could always see the packets, and could always perform any attack that he wanted. >>>> That said, and as noted above, it is interesting to offer alternatives. >>>> For example, if you implement the hash-based approach described in my >>>> I-D, the first flow label is "expensive", but the rest are really cheap: >>>> e.g., just add the counter to the value of F() that you have recorded in >>>> the destinations cache. OTOH, randomizing every FlowLabel might be more >>>> expensive. >>> That depends on how much extra you pay for holding state in the destinations >>> cache. A stateless algorithm avoids that. >> >> The destinations cache is already there. So a few bytes per entry does >> not seem to be a big deal. -- and if it is, then you'd probably be >> concerned about having the Destinations Cache in the first place.... > > It's an engineering trade-off, certainly. My taste is always to avoid > extra state, however. Four bytes per IP address (*not* per TCP connection or the like) doesn't seem like a big deal. -- You're going to hit many other problems before those four extra bytes become a problem. That said, I'm generally in favour of offering choices, discussing the trade-offs, and let people pick the option that they like most. >> I'm fine with not describing any algorithms in the base expect. But I do >> think that something along the lines of RFC 6056 is needed -- everytime >> something like that was misswing, people got it wrong. Thing about IP >> ID, TCP port numbers, etc., etc. > > Yes, but maybe we need a little experience first. That's why I have a > student playing with the largest IPv6 traces we've managed to get hold > of. Experimental data is always good. However, regardless of what the results of this experiment are, let's just say that with the current levels of v6 deployment, it's hard to tell whether those results will still hold in, say, two years, or whatever. Different systems use different address types, addresses selection algorithms, etc., that are likely to evolve over time (not to mention the traffic patterns). So I'm more of the idea that the aforementioned experiment could help to identify algorithms that suck, but not really prove that this or that algorithm is (or will be) best (assuming that there's such a thing -- which I don't think it's the case... there are just different options, with different trade-offs). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian@innovationslab.net Wed Jan 25 05:43:49 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B8F21F856A for ; Wed, 25 Jan 2012 05:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyADzrV3wLLE for ; Wed, 25 Jan 2012 05:43:48 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D504321F854A for ; Wed, 25 Jan 2012 05:43:48 -0800 (PST) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C241F88099 for ; Wed, 25 Jan 2012 05:43:48 -0800 (PST) Received: from clemson.jhuapl.edu (unknown [128.244.243.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 71A57130002 for ; Wed, 25 Jan 2012 05:43:48 -0800 (PST) Message-ID: <4F200713.6070609@innovationslab.net> Date: Wed, 25 Jan 2012 08:43:47 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> <4F1FD701.9050402@si6networks.com> In-Reply-To: <4F1FD701.9050402@si6networks.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 13:43:49 -0000 Fernando, On 1/25/12 5:18 AM, Fernando Gont wrote: > On 01/24/2012 11:39 PM, Brian E Carpenter wrote: >>>>> If the attacker can *observe* labels, why would he bother to "guess" them? >>>> So that s/he can generate plausible bogons as part of a DOS attack. It seems >>>> to me that predictability of the flow label is similar to predictability >>>> of port numbers in that respect. >>> >>> Let me rephrase with two questions: >>> >>> a) If an attacker is off-path, how can he "attack" the algorithm >>> proposed in "draft-gont-6man-flowlabel-security-02.txt"? >> >> OK, I mean an attacker who is able to observe the traffic but not >> perform MITM modifications. Some people call that off-path... > > Well, the attacker *is* on the path if he can observe traffic. > > That said, if the attacker is able to observe traffic, then game over. > Whether we use random FlowLabels or predictable FlowLabels is the same: > the attacker is not going to waste his time "guessing" when he can learn > the labels by listening to traffic. I think you and Brian C. are not talking about the same issue. Brian C. is talking about being able to see current flow labels and then being able to guess future flow labels. That is, the attacker has the ability to forge traffic for a future exchange. You seem to be focused on the observation of a current flow and the attacker being able to inject traffic into that flow. > > > >>> b) If an attacker is on-path how does any algorithm prevent the attacker >>> from *knowing* which FlowLabels he should forge? >> >> Obviously for an established flow, you can inject forged packets that >> appear to belong to that flow; we can never prevent this. But if you >> can predict the flow label for *future* flows, you can forge and >> inject SYN packets before the real user ever starts the flow. Since >> a large part of today's forged traffic seems to consist of SYN packets, >> this seems like a sensitive target. > > Since FlowLabels do not carry any specific semantics, I cannot see how > "forge and inject before..." would be any worse than firing those > packets once the flow has already been established. Injection of state into the endpoints may influence a large number of functions, so an attacker's ability to forge packets may allow it to skew the behavior of one of the nodes. > > That aside, as noted above, the attacker could only predict flowlabels > if he is on-path. And if the attacker is on-path, game over. I don't think that is completely true. If the attacker cannot guess the future flow label correctly, its attempts may be detected. Regards, Brian H. From fgont@si6networks.com Wed Jan 25 06:07:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC18521F8615 for ; Wed, 25 Jan 2012 06:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiU85gk+-zxe for ; Wed, 25 Jan 2012 06:07:59 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1269C21F8648 for ; Wed, 25 Jan 2012 06:07:59 -0800 (PST) Received: from [190.48.247.231] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rq3W0-0003S9-Hl; Wed, 25 Jan 2012 15:07:56 +0100 Message-ID: <4F200CB5.4080907@si6networks.com> Date: Wed, 25 Jan 2012 11:07:49 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian Haberman Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> <4F1FD701.9050402@si6networks.com> <4F200713.6070609@innovationslab.net> In-Reply-To: <4F200713.6070609@innovationslab.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:08:00 -0000 On 01/25/2012 10:43 AM, Brian Haberman wrote: >> That said, if the attacker is able to observe traffic, then game over. >> Whether we use random FlowLabels or predictable FlowLabels is the same: >> the attacker is not going to waste his time "guessing" when he can learn >> the labels by listening to traffic. > > I think you and Brian C. are not talking about the same issue. Brian C. > is talking about being able to see current flow labels and then being > able to guess future flow labels. That is, the attacker has the ability > to forge traffic for a future exchange. You seem to be focused on the > observation of a current flow and the attacker being able to inject > traffic into that flow. Agreed. The point I'm trying to make is that I do not see what the attacker would gain from guessing a label that's not in use yet. For instance, if he were to send packets with that forged label, the spoofed traffic might not event "compete" with any existing traffic. >> Since FlowLabels do not carry any specific semantics, I cannot see how >> "forge and inject before..." would be any worse than firing those >> packets once the flow has already been established. > > Injection of state into the endpoints may influence a large number of > functions, so an attacker's ability to forge packets may allow it to > skew the behavior of one of the nodes. Not sure what you mean.... >> That aside, as noted above, the attacker could only predict flowlabels >> if he is on-path. And if the attacker is on-path, game over. > > I don't think that is completely true. If the attacker cannot guess the > future flow label correctly, its attempts may be detected. How? And more importantly, why would an attacker want to forge a future label that is not in use? Let's keep in mind that if the attacker is on-path, that of attacking the flow label is probably the last DoS variant an attacker could try (no amplification, etc.) Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rja.lists@gmail.com Wed Jan 25 06:14:16 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8230621F8678 for ; Wed, 25 Jan 2012 06:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.607 X-Spam-Level: X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDBxuYqpkAoY for ; Wed, 25 Jan 2012 06:14:16 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 00EC821F8671 for ; Wed, 25 Jan 2012 06:14:15 -0800 (PST) Received: by qady23 with SMTP id y23so867115qad.10 for ; Wed, 25 Jan 2012 06:14:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=K9sHxITp2SLZzufmPTgjflttEVBzE/mLY0T2sRhbeDk=; b=QOX7ri95RcPqR2IAd6SR+10q9roVBZeLqGJLpN96cGQ2NyDj9IUa4HI1CRIUyyrpAB wc0fo4WpzPBy/MdFzeg4eVEfgG5ZhBzRcr5dsrd54I1xuHKBs5yL7fohQd42dNKI/UMh tJKzr74Yu/kI4mTeqlUmBHXEN/6s3r1mESaS4= Received: by 10.224.18.83 with SMTP id v19mr13840982qaa.43.1327500855443; Wed, 25 Jan 2012 06:14:15 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id eb5sm2191312qab.10.2012.01.25.06.14.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 06:14:14 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments Date: Wed, 25 Jan 2012 09:14:12 -0500 Message-Id: <30DCC933-883E-462C-82AE-61C2AB54B097@gmail.com> To: ipv6@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:14:16 -0000 I support adopting this as a WG document. Ran From brian.e.carpenter@gmail.com Wed Jan 25 12:08:53 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A527611E808E for ; Wed, 25 Jan 2012 12:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwaUG2jHi5Ga for ; Wed, 25 Jan 2012 12:08:53 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DAC3411E8089 for ; Wed, 25 Jan 2012 12:08:52 -0800 (PST) Received: by ggnq4 with SMTP id q4so2492702ggn.31 for ; Wed, 25 Jan 2012 12:08:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=exo++gUrmXQoiG/sUOxUS5MdRrnCiGyMjIWvdtcV/H0=; b=U4lUPXnc7k7QqlM1UxFXq26YvxWm4HyRK/95NUkB+3YAA4EYPYZAjehM/QplZHrpmg YH63Ys/o2Wsl4j/h/obs4ioHNR2NSA9V/HX+oKJwPOGicd1jyzoWbcYdZTAi8JAuiFxh yBzYusrYLkL2+sBJ/7km9L1K/PFMorjIdpO6s= Received: by 10.50.34.202 with SMTP id b10mr10205940igj.30.1327522132414; Wed, 25 Jan 2012 12:08:52 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id or2sm393869igc.5.2012.01.25.12.08.48 (version=SSLv3 cipher=OTHER); Wed, 25 Jan 2012 12:08:50 -0800 (PST) Message-ID: <4F20614E.9000102@gmail.com> Date: Thu, 26 Jan 2012 09:08:46 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> <4F1FD701.9050402@si6networks.com> <4F200713.6070609@innovationslab.net> <4F200CB5.4080907@si6networks.com> In-Reply-To: <4F200CB5.4080907@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:08:53 -0000 On 2012-01-26 03:07, Fernando Gont wrote: > On 01/25/2012 10:43 AM, Brian Haberman wrote: > >>> That said, if the attacker is able to observe traffic, then game over. >>> Whether we use random FlowLabels or predictable FlowLabels is the same: >>> the attacker is not going to waste his time "guessing" when he can learn >>> the labels by listening to traffic. >> I think you and Brian C. are not talking about the same issue. Brian C. >> is talking about being able to see current flow labels and then being >> able to guess future flow labels. That is, the attacker has the ability >> to forge traffic for a future exchange. You seem to be focused on the >> observation of a current flow and the attacker being able to inject >> traffic into that flow. > > Agreed. The point I'm trying to make is that I do not see what the > attacker would gain from guessing a label that's not in use yet. For > instance, if he were to send packets with that forged label, the spoofed > traffic might not event "compete" with any existing traffic. One case that I'm thinking of specifically is if the attacker also knows the load balancing algorithm in use, and in particular how it interacts with the flow label, then there might be a way to bias the load balancing and orchestrate a DOS SYN attack on a particular server. All I'm saying is that *any* kind of predictability of future flows is a weakness that we should avoid. > > >>> Since FlowLabels do not carry any specific semantics, I cannot see how >>> "forge and inject before..." would be any worse than firing those >>> packets once the flow has already been established. >> Injection of state into the endpoints may influence a large number of >> functions, so an attacker's ability to forge packets may allow it to >> skew the behavior of one of the nodes. > > Not sure what you mean.... Load balancing is an example. I think you'd be courageous to assert that the bad guys won't find another. > > > >>> That aside, as noted above, the attacker could only predict flowlabels >>> if he is on-path. And if the attacker is on-path, game over. >> I don't think that is completely true. If the attacker cannot guess the >> future flow label correctly, its attempts may be detected. > > How? And more importantly, why would an attacker want to forge a future > label that is not in use? > > Let's keep in mind that if the attacker is on-path, that of attacking > the flow label is probably the last DoS variant an attacker could try > (no amplification, etc.) They will try anything that works, in the end. I think it's very cheap to avoid this risk - in your notation, it means Flow Label = counter + F(Source Address, Destination Address, Secret Key) is changed to Flow Label = F(Source Address, Destination Address, Secret Key, counter) That means that the regularity introduced by the counter is hidden by the hash function. Brian From Tina.Tsou.Zouting@huawei.com Wed Jan 25 14:09:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B51B21F8554 for ; Wed, 25 Jan 2012 14:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJCNqJ4oj4kB for ; Wed, 25 Jan 2012 14:09:01 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id CCB3521F856C for ; Wed, 25 Jan 2012 14:09:00 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYD004U7K6VO3@szxga03-in.huawei.com> for ipv6@ietf.org; Thu, 26 Jan 2012 06:08:55 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYD008DIK6NFH@szxga03-in.huawei.com> for ipv6@ietf.org; Thu, 26 Jan 2012 06:08:55 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGO63834; Thu, 26 Jan 2012 06:08:53 +0800 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 26 Jan 2012 06:08:38 +0800 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.225]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Thu, 26 Jan 2012 06:08:47 +0800 Date: Wed, 25 Jan 2012 22:08:46 +0000 From: Tina TSOU Subject: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments In-reply-to: <30DCC933-883E-462C-82AE-61C2AB54B097@gmail.com> To: RJ Atkinson Message-id: <9EAC6D18-3847-408A-8ACE-BF245C6ADD13@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments Thread-index: AQHM22unuldePF86O0yMONsQMShfhJYdpPkt X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <30DCC933-883E-462C-82AE-61C2AB54B097@gmail.com> Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:09:01 -0000 +1 Sent from my iPad On Jan 25, 2012, at 6:14 AM, "RJ Atkinson" wrote: > > I support adopting this as a WG document. > > Ran > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Thu Jan 26 04:02:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0ED21F85BD for ; Thu, 26 Jan 2012 04:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaOoVPSDZ1w0 for ; Thu, 26 Jan 2012 04:02:14 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id EE66C21F85C0 for ; Thu, 26 Jan 2012 04:02:13 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.109]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqO1q-0004ZX-Ms; Thu, 26 Jan 2012 13:02:11 +0100 Message-ID: <4F2130D4.4010707@si6networks.com> Date: Thu, 26 Jan 2012 07:54:12 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> <4F1FD701.9050402@si6networks.com> <4F200713.6070609@innovationslab.net> <4F200CB5.4080907@si6networks.com> <4F20614E.9000102@gmail.com> In-Reply-To: <4F20614E.9000102@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:02:14 -0000 Hi, Brian, On 01/25/2012 05:08 PM, Brian E Carpenter wrote: >> Agreed. The point I'm trying to make is that I do not see what the >> attacker would gain from guessing a label that's not in use yet. For >> instance, if he were to send packets with that forged label, the spoofed >> traffic might not event "compete" with any existing traffic. > > One case that I'm thinking of specifically is if the attacker also knows > the load balancing algorithm in use, One should expect the attacker to know the load-balancing algorithm, but not the parameters with which it operates. If the attacker knows all of these things (algorithm+parameters), then *that* is where the flaw is (assuming having the attacker play with load-balancing is a concern, of course). > and in particular how it interacts > with the flow label, then there might be a way to bias the load balancing > and orchestrate a DOS SYN attack on a particular server. Not sure what you mean. Are you arguing that in this case the flow-label would be used for *server* load-balancing? > All I'm saying is > that *any* kind of predictability of future flows is a weakness that we > should avoid. I'm generally of the idea that "random is your friend" (wherever possible). That said, I'm also arguing that when analyzing the security properties of something, the threat model should be clearly defined. For yet another example, draft-gont-predictable-fragment-id. My original proposal was to simply randomize the Fragment Identification. But concerns with collisions of Fragment IDs led to alternative approaches (although I personally think that that doesn't mean that simple Fragment ID randomization should be ruled out). >>>> Since FlowLabels do not carry any specific semantics, I cannot see how >>>> "forge and inject before..." would be any worse than firing those >>>> packets once the flow has already been established. >>> Injection of state into the endpoints may influence a large number of >>> functions, so an attacker's ability to forge packets may allow it to >>> skew the behavior of one of the nodes. >> >> Not sure what you mean.... > > Load balancing is an example. I think you'd be courageous to assert > that the bad guys won't find another. I just have not seen any example in which an algorithm such as the one in "draft-gont-6man-flowlabel-security-02" would allow an attacker to do something that he cannot do with randomized (as in rand()) FlowLabels. And I'm just saying that if the attacker is on-path, what algorithm you use is mostly irrelevant. >> How? And more importantly, why would an attacker want to forge a future >> label that is not in use? >> >> Let's keep in mind that if the attacker is on-path, that of attacking >> the flow label is probably the last DoS variant an attacker could try >> (no amplification, etc.) > > They will try anything that works, Again: Is there any benefit an attacker would get from knowing what FLs might be used in the future? For instance, if the FLs are not in use, it doesn't seem to make sense for an attacker to start firing packets with such labels, as those packet would not compete with the "real ones". And if the attacker is on-path, then he'll play lazy, and would simply learn the labels from the wire. > in the end. I think it's very cheap > to avoid this risk - in your notation, it means > > Flow Label = counter + F(Source Address, Destination Address, Secret Key) > > is changed to > > Flow Label = F(Source Address, Destination Address, Secret Key, counter) > > That means that the regularity introduced by the counter is hidden by > the hash function. This also means that the algorithm is now broken. The goal of F() is to produce a constant value for each set (src IP, dst IP), which cannot be easily guessable by an off-path attacker (F() introduces the randomization). Then counter is incremented for each new label, such that for each set (src IP, dst IP) you get monotonically-increasing flow bales, such that the FL reuse frequency is minimized (please see the sampl output in the I-D). If you introduce "counter" within F(), it's like changing the secret key for every flow label, at which point the result of F() is probably not better than than of "rand()". Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From aservin@lacnic.net Thu Jan 26 04:59:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A112721F869F for ; Thu, 26 Jan 2012 04:59:18 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3GG1E8nOXK3 for ; Thu, 26 Jan 2012 04:59:18 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 08F0321F8707 for ; Thu, 26 Jan 2012 04:59:18 -0800 (PST) Received: from [IPv6:2001:13c7:7001:5128:b87a:7969:b6ad:4148] (unknown [IPv6:2001:13c7:7001:5128:b87a:7969:b6ad:4148]) by mail.lacnic.net.uy (Postfix) with ESMTP id A701C30843C; Thu, 26 Jan 2012 10:59:03 -0200 (UYST) Subject: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Arturo Servin In-Reply-To: <4F148730.6030308@innovationslab.net> Date: Thu, 26 Jan 2012 10:59:02 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CB80761-33D4-488F-9E1E-BC47C8F9AE2D@lacnic.net> References: <4F148730.6030308@innovationslab.net> To: IPv6 WG Mailing List X-Mailer: Apple Mail (2.1251.1) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Brian Haberman X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 12:59:18 -0000 Support to adopt as WG document. Couple of questions. Fernando, When you say "Namely, they try to perform IPv6 reassembly with the "atomic fragment" and any other fragments already queued with the same set {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}." If there is just one packet what = happen? Does the host just hang in there waiting for the next fragment = (that possibly will never arrive) until it times out? Also, you quoted RFC2640 "In response to an IPv6 packet that is = sent to an IPv4 destination (i.e., a packet that undergoes translation from IPv6 to IPv4) =85" = I wonder if there is any negative implication for IPv4/IPv6 translators = if atomic fragments are forbidden as proposed. Regards, .as On 16 Jan 2012, at 18:23, Brian Haberman wrote: > All, > This is a consensus call on adopting: >=20 > Title : Processing of IPv6 "atomic" fragments > Author(s) : Fernando Gont > Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt > Pages : 12 > Date : 2011-12-15 >=20 > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus = call > will end on January 31, 2012. >=20 > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From fgont@si6networks.com Thu Jan 26 15:17:52 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF7D21F8733 for ; Thu, 26 Jan 2012 15:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8RFZU-eYwyr for ; Thu, 26 Jan 2012 15:17:51 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 71DB621F864D for ; Thu, 26 Jan 2012 15:17:51 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.110]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqYZd-0000pp-Sq; Fri, 27 Jan 2012 00:17:46 +0100 Message-ID: <4F215C79.9050905@si6networks.com> Date: Thu, 26 Jan 2012 11:00:25 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Arturo Servin Subject: Reassembly of atomic fragments (was: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments) References: <4F148730.6030308@innovationslab.net> <2CB80761-33D4-488F-9E1E-BC47C8F9AE2D@lacnic.net> In-Reply-To: <2CB80761-33D4-488F-9E1E-BC47C8F9AE2D@lacnic.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Brian Haberman , IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 23:17:52 -0000 [Subject changed so that this doesn't "mix" with the poll] Hi, Arturo, On 01/26/2012 09:59 AM, Arturo Servin wrote: > When you say "Namely, they try to perform IPv6 reassembly with the > "atomic fragment" and any other fragments already queued with the > same set {IPv6 Source Address, IPv6 Destination Address, Fragment > Identification}." If there is just one packet what happen? Does the > host just hang in there waiting for the next fragment (that possibly > will never arrive) until it times out? I didn't test *this* one (will do this weekend, and let you know). But they *do* mix the atomic fragment with fragments present in the fragment queue. That is, the attacker (knowing that you're relying on atomic fragments) can send lots of forged fragments to the victim system, such that when your legitimate fragments arrive at the victim they get mixed up with the malicious fragments, and hence they get discarded. > Also, you quoted RFC2640 "In response to an IPv6 packet that is sent > to an IPv4 destination (i.e., a packet that undergoes translation > from IPv6 to IPv4) …" I wonder if there is any negative implication > for IPv4/IPv6 translators if atomic fragments are forbidden as > proposed. Dan Wing has noted that forbidding atomic fragments breaks RFC 6144. It would also break the DNS if atomic fragments are employed for it. That's why draft-gont-6man-ipv6-atomic-fragments does *not* forbid atomic fragments, but rather improves the their processing at the receiving node. Essentially, what this proposal says "If you receive an atomic fragment, don't 'merge it' with fragmented traffic, but just remove the Fragmentation Header and process the packet as if it was not fragmented". Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fweimer@bfk.de Fri Jan 27 02:27:09 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBA421F852D for ; Fri, 27 Jan 2012 02:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjELeTV2vwwn for ; Fri, 27 Jan 2012 02:27:08 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 800F021F84CE for ; Fri, 27 Jan 2012 02:27:08 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rqj1O-0001Uc-Sx; Fri, 27 Jan 2012 10:27:06 +0000 Received: by bfk.de with local id 1Rqj1O-0002UB-P0; Fri, 27 Jan 2012 10:27:06 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> Date: Fri, 27 Jan 2012 10:27:06 +0000 In-Reply-To: <82d3bfbm5l.fsf@mid.bfk.de> (Florian Weimer's message of "Fri, 23 Dec 2011 10:46:46 +0000") Message-ID: <82aa59sao5.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:27:09 -0000 * Florian Weimer: > Actually, atomic fragments aren't the problem, but the technology that > serves as a justification for them. [...] This argument turns out to be entirely wrong. Sorry about that. I'm still extremely bothered by atomic fragments. Their use case seems to be something like this: (1) A router receives a sufficiently large IPv6 packet for a destination which lies behind a link with a sub-1280 MTU. (2) The router sees that the packet lacks a Fragment extension header. It sends a Packet Too Big ICMP message to the source address and discards the original packet. (3) The source retransmits the packet, this time with an extension header describing it as an atomic fragment. (4) It arrives at the router of step (1). The device now fragments the atomic fragment packet into actual fragmented packets, and forwards it over the sub-1280 link. This is contrary to the IPv6 design because the network is not supposed to fragment. But it has to, due to the sub-1280 link, or there wouldn't be any IPv6 connectivity at all. Once you accept this deviation from the IPv6 specification, why can't the router jump from step (1) to step (4), after synthesizing a Fragment extension header locally? It's not that the header contains valuable application data or something like that. It seems to me that this results in superior interoperability: it works with nodes which do not support atomic fragments gracefully, and it doesn't require updates to significant parts of the network, to generate atomic fragments more reliably *and* to deal with the resulting increase in atomic fragments. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Fri Jan 27 02:49:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888AE21F8537 for ; Fri, 27 Jan 2012 02:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8FuWgZ2+qGA for ; Fri, 27 Jan 2012 02:49:47 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id D923E21F853F for ; Fri, 27 Jan 2012 02:49:45 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RqjNI-000394-3P for ipv6@ietf.org; Fri, 27 Jan 2012 10:49:44 +0000 Received: by bfk.de with local id 1RqjNI-00018m-0X for ipv6@ietf.org; Fri, 27 Jan 2012 10:49:44 +0000 From: Florian Weimer To: "ipv6\@ietf.org" Subject: Re: New revision of draft-gont-6man-flowlabel-security References: <4F10300E.1040606@si6networks.com> Date: Fri, 27 Jan 2012 10:49:44 +0000 In-Reply-To: <4F10300E.1040606@si6networks.com> (Fernando Gont's message of "Fri, 13 Jan 2012 10:22:22 -0300") Message-ID: <8239b1s9mf.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:49:47 -0000 * Fernando Gont: > I have just posted a revision of the aforementioned I-D. It is available > at: > > Any comments will be appreciated. Destination-specific counters introduce state keeping requirements and concurrency bottlenecks. Are those really necessary? I would like to see actual use of the flow label field which doesn't suffer from denial of service issues (by creating many flows with the same label, undermining things like label-based load distribution) or traffic parasitism. Furthermore, RFC 6437 allows modification of the flow label header in transit, so I really doubt that there are any such applications. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pch-b29AA871B@u-1.phicoh.com Fri Jan 27 03:13:14 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D2A21F8554 for ; Fri, 27 Jan 2012 03:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.311 X-Spam-Level: X-Spam-Status: No, score=-8.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZLFJUGiQV-2 for ; Fri, 27 Jan 2012 03:13:13 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 74FE521F8543 for ; Fri, 27 Jan 2012 03:13:13 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rqjjw-0001oHC; Fri, 27 Jan 2012 12:13:08 +0100 Message-Id: To: Florian Weimer Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> In-reply-to: Your message of "Fri, 27 Jan 2012 10:27:06 +0000 ." <82aa59sao5.fsf@mid.bfk.de> Date: Fri, 27 Jan 2012 12:13:07 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 11:13:14 -0000 In your letter dated Fri, 27 Jan 2012 10:27:06 +0000 you wrote: >I'm still extremely bothered by atomic fragments. Their use case seems >to be something like this: > > (1) A router receives a sufficiently large IPv6 packet for a > destination which lies behind a link with a sub-1280 MTU. > > (2) The router sees that the packet lacks a Fragment extension header. > It sends a Packet Too Big ICMP message to the source address and > discards the original packet. > > (3) The source retransmits the packet, this time with an extension > header describing it as an atomic fragment. > > (4) It arrives at the router of step (1). The device now fragments > the atomic fragment packet into actual fragmented packets, and > forwards it over the sub-1280 link. > >This is contrary to the IPv6 design because the network is not supposed >to fragment. The original use case was slightly different. It was about IPv6/IPv4 translators. The translator tries to forward an IPv6 packet or fragment over IPv4 where it requires fragmentation. Now we need a unique identifier for the IPv4 packet. Solution: require the host to insert a fragment header which contains a unique id. Given the current trends, just a random number would be good enough. But the old RFCs assumed that a sequence number was used to maintain uniqueness. From fweimer@bfk.de Fri Jan 27 03:36:29 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C721F8581 for ; Fri, 27 Jan 2012 03:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCJuDvCx3xmZ for ; Fri, 27 Jan 2012 03:36:29 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0422821F8579 for ; Fri, 27 Jan 2012 03:36:28 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rqk6U-0006VI-LT; Fri, 27 Jan 2012 11:36:26 +0000 Received: by bfk.de with local id 1Rqk6U-0008QT-Fw; Fri, 27 Jan 2012 11:36:26 +0000 From: Florian Weimer To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> Date: Fri, 27 Jan 2012 11:36:26 +0000 In-Reply-To: (Philip Homburg's message of "Fri, 27 Jan 2012 12:13:07 +0100") Message-ID: <82vcnxqsw5.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 11:36:29 -0000 * Philip Homburg: >>This is contrary to the IPv6 design because the network is not supposed >>to fragment.=20=20 > > The original use case was slightly different. It was about IPv6/IPv4 > translators. The translator tries to forward an IPv6 packet or fragment o= ver > IPv4 where it requires fragmentation. Now we need a unique identifier for > the IPv4 packet. Solution: require the host to insert a fragment header w= hich > contains a unique id. And I see no functional difference between the gateway and the host generating the fragment ID, except that the latter approach seems to require network-wide software updates currently. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fgont@si6networks.com Fri Jan 27 04:02:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E821F8572 for ; Fri, 27 Jan 2012 04:02:10 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B1E47xuUZut for ; Fri, 27 Jan 2012 04:02:10 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2A121F856F for ; Fri, 27 Jan 2012 04:02:10 -0800 (PST) Received: from [24.232.158.65] (helo=[192.168.88.248]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqkVJ-0006Kz-EB; Fri, 27 Jan 2012 13:02:05 +0100 Message-ID: <4F22922A.1090603@si6networks.com> Date: Fri, 27 Jan 2012 09:01:46 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> In-Reply-To: <82vcnxqsw5.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 12:02:10 -0000 On 01/27/2012 08:36 AM, Florian Weimer wrote: > And I see no functional difference between the gateway and the host > generating the fragment ID, except that the latter approach seems to > require network-wide software updates currently. Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by inserting a Fragment Header in subsequent packets, or what? (last time I checked, I think this was the case) As noted by Dan Wing, there's stuff that would break. In any, please note the difference between *accepting* atomic fragments, generating ICMPv6 PTB when the MTU of the constricting link is < 1280, and reacting to ICMPv6 PTB by generating atomic fragments. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Fri Jan 27 04:09:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E70721F8567 for ; Fri, 27 Jan 2012 04:09:19 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07Fg2HEbUH+y for ; Fri, 27 Jan 2012 04:09:18 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id A9EED21F854F for ; Fri, 27 Jan 2012 04:09:18 -0800 (PST) Received: from [24.232.158.65] (helo=[192.168.88.248]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqkcH-0006Nc-1E; Fri, 27 Jan 2012 13:09:17 +0100 Message-ID: <4F2293E9.60201@si6networks.com> Date: Fri, 27 Jan 2012 09:09:13 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: New revision of draft-gont-6man-flowlabel-security References: <4F10300E.1040606@si6networks.com> <8239b1s9mf.fsf@mid.bfk.de> In-Reply-To: <8239b1s9mf.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 12:09:19 -0000 On 01/27/2012 07:49 AM, Florian Weimer wrote: >> I have just posted a revision of the aforementioned I-D. It is available >> at: >> >> Any comments will be appreciated. > > Destination-specific counters introduce state keeping requirements and > concurrency bottlenecks. Are those really necessary? There are no "destination-specific" counters. Just a global counter, or a set of counters (for the double-hash algorithm). > I would like to see actual use of the flow label field which doesn't > suffer from denial of service issues (by creating many flows with the > same label, Well, *this* is no different from doing load-sharing based on the five-tuple (protocop, src ip, srp port, dst ip, dst port). > undermining things like label-based load distribution) or > traffic parasitism. Furthermore, RFC 6437 allows modification of the > flow label header in transit, so I really doubt that there are any such > applications. There's no checksum on the Flow Label, and it's not even protected by IPsec, so... how could RFC6437 possibly "forbid modification of the flow label"? (other than "nodes MUST NOT modify the FL....Good *luck*, btw!") Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fweimer@bfk.de Fri Jan 27 04:14:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68F921F8539 for ; Fri, 27 Jan 2012 04:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbaohfBNcqUD for ; Fri, 27 Jan 2012 04:14:33 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 171F921F8523 for ; Fri, 27 Jan 2012 04:14:32 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RqkhK-0000ZR-2c; Fri, 27 Jan 2012 12:14:30 +0000 Received: by bfk.de with local id 1RqkhJ-0000zF-VA; Fri, 27 Jan 2012 12:14:29 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> Date: Fri, 27 Jan 2012 12:14:29 +0000 In-Reply-To: <4F22922A.1090603@si6networks.com> (Fernando Gont's message of "Fri, 27 Jan 2012 09:01:46 -0300") Message-ID: <82r4ylqr4q.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 12:14:33 -0000 * Fernando Gont: > On 01/27/2012 08:36 AM, Florian Weimer wrote: >> And I see no functional difference between the gateway and the host >> generating the fragment ID, except that the latter approach seems to >> require network-wide software updates currently. > > Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by > inserting a Fragment Header in subsequent packets, or what? (last time I > checked, I think this was the case) There are existing deployments which effectively filter ICMPv6 traffic. Some of them do so explicitly, others simply to do not broadcast incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to make this work with behind a per-packet load balancer). Naked host behavior does not matter in such scenarios. As soon as IPv6 traffic levels increase, all busy UDP sources will stop generating atomic fragments reliably because at the time of retry, the fact that an atomic fragment is required has expired from the destination cache (if there is one in the first place, that is). That's why Mark proposes to send atomic fragments unconditionally and *that* is known to break stuff for sure. > In any, please note the difference between *accepting* atomic fragments, > generating ICMPv6 PTB when the MTU of the constricting link is < 1280, > and reacting to ICMPv6 PTB by generating atomic fragments. True, but why would it be important to accept atomic fragments, when the system as a whole does not actually generate them properly? I'm worried that we're imposing updates on significant parts of the network to address an issue that could also be fixed locally, maintaining full interoperability with the rest of the network as it exists now. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From pch-b29AA871B@u-1.phicoh.com Fri Jan 27 04:23:19 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6269D21F8546 for ; Fri, 27 Jan 2012 04:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.369 X-Spam-Level: X-Spam-Status: No, score=-8.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ9vXfsThZxd for ; Fri, 27 Jan 2012 04:23:19 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 94FED21F8526 for ; Fri, 27 Jan 2012 04:23:18 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rqkpn-0001oKC; Fri, 27 Jan 2012 13:23:15 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> In-reply-to: Your message of "Fri, 27 Jan 2012 09:01:46 -0300 ." <4F22922A.1090603@si6networks.com> Date: Fri, 27 Jan 2012 13:23:14 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 12:23:19 -0000 In your letter dated Fri, 27 Jan 2012 09:01:46 -0300 you wrote: >In any, please note the difference between *accepting* atomic fragments, >generating ICMPv6 PTB when the MTU of the constricting link is < 1280, >and reacting to ICMPv6 PTB by generating atomic fragments. My strong preference would be to kill this whole atomic fragment stuff before it goes any further. The sole purpose of atomic fragments seems to be to be able to copy a random number generated by the host instead of generating one locally in a gateway/translator. (I assume that any server, certainly bigger DNS servers, will have trouble maintaining destination cache entries long enough to ensure that there will be no collissions. Thus reducing id generation to just random) From fweimer@bfk.de Fri Jan 27 05:06:47 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC13321F8541 for ; Fri, 27 Jan 2012 05:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=1.234, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EePeIF8M4YfV for ; Fri, 27 Jan 2012 05:06:47 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id D414F21F8510 for ; Fri, 27 Jan 2012 05:06:46 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RqlVs-0003oU-8a; Fri, 27 Jan 2012 13:06:44 +0000 Received: by bfk.de with local id 1RqlVs-0001fx-44; Fri, 27 Jan 2012 13:06:44 +0000 From: Florian Weimer To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> Date: Fri, 27 Jan 2012 13:06:44 +0000 In-Reply-To: (Philip Homburg's message of "Fri, 27 Jan 2012 13:23:14 +0100") Message-ID: <82ehulqopn.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 13:06:47 -0000 * Philip Homburg: > In your letter dated Fri, 27 Jan 2012 09:01:46 -0300 you wrote: >>In any, please note the difference between *accepting* atomic fragments, >>generating ICMPv6 PTB when the MTU of the constricting link is < 1280, >>and reacting to ICMPv6 PTB by generating atomic fragments. > > My strong preference would be to kill this whole atomic fragment stuff be= fore > it goes any further. In case this isn't obvious, this is my feeling as well. I'm still looking for a justification for the complexity of preserving this protocol aspect, but I doubt there is one. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From aservin@lacnic.net Fri Jan 27 06:40:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA7721F85A8 for ; Fri, 27 Jan 2012 06:40:00 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z9C8G5M+wRz for ; Fri, 27 Jan 2012 06:39:59 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id E8DD521F857D for ; Fri, 27 Jan 2012 06:39:57 -0800 (PST) Received: from [IPv6:2001:13c7:7001:5128:f530:1fe:4d46:643b] (unknown [IPv6:2001:13c7:7001:5128:f530:1fe:4d46:643b]) by mail.lacnic.net.uy (Postfix) with ESMTP id 9720D308453; Fri, 27 Jan 2012 12:39:52 -0200 (UYST) Subject: Re: Reassembly of atomic fragments (was: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Arturo Servin In-Reply-To: <4F215C79.9050905@si6networks.com> Date: Fri, 27 Jan 2012 12:39:52 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49A28BF1-B888-4FEF-A6AD-4A46BE247403@lacnic.net> References: <4F148730.6030308@innovationslab.net> <2CB80761-33D4-488F-9E1E-BC47C8F9AE2D@lacnic.net> <4F215C79.9050905@si6networks.com> To: Fernando Gont X-Mailer: Apple Mail (2.1251.1) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: 6man Chairs <6man-chairs@tools.ietf.org>, Brian Haberman , IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 14:40:00 -0000 Thanks. It is clear now. .as On 26 Jan 2012, at 12:00, Fernando Gont wrote: > [Subject changed so that this doesn't "mix" with the poll] >=20 > Hi, Arturo, >=20 > On 01/26/2012 09:59 AM, Arturo Servin wrote: >> When you say "Namely, they try to perform IPv6 reassembly with the >> "atomic fragment" and any other fragments already queued with the >> same set {IPv6 Source Address, IPv6 Destination Address, Fragment >> Identification}." If there is just one packet what happen? Does the >> host just hang in there waiting for the next fragment (that possibly >> will never arrive) until it times out? >=20 > I didn't test *this* one (will do this weekend, and let you know). But > they *do* mix the atomic fragment with fragments present in the = fragment > queue. That is, the attacker (knowing that you're relying on atomic > fragments) can send lots of forged fragments to the victim system, = such > that when your legitimate fragments arrive at the victim they get = mixed > up with the malicious fragments, and hence they get discarded. >=20 >=20 >> Also, you quoted RFC2640 "In response to an IPv6 packet that is sent >> to an IPv4 destination (i.e., a packet that undergoes translation >> from IPv6 to IPv4) =85" I wonder if there is any negative implication >> for IPv4/IPv6 translators if atomic fragments are forbidden as >> proposed. >=20 > Dan Wing has noted that forbidding atomic fragments breaks RFC 6144. = It > would also break the DNS if atomic fragments are employed for it. >=20 > That's why draft-gont-6man-ipv6-atomic-fragments does *not* forbid > atomic fragments, but rather improves the their processing at the > receiving node. >=20 > Essentially, what this proposal says "If you receive an atomic = fragment, > don't 'merge it' with fragmented traffic, but just remove the > Fragmentation Header and process the packet as if it was not = fragmented". >=20 > Thanks! >=20 > Best regards, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 From fgont@si6networks.com Fri Jan 27 08:13:05 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A2521F8507 for ; Fri, 27 Jan 2012 08:13:05 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVYlzpZk3aoM for ; Fri, 27 Jan 2012 08:13:05 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id F391721F84FD for ; Fri, 27 Jan 2012 08:13:04 -0800 (PST) Received: from [24.232.158.65] (helo=[192.168.88.248]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqoQ8-0007zE-CM; Fri, 27 Jan 2012 17:13:02 +0100 Message-ID: <4F22CBCA.5040106@si6networks.com> Date: Fri, 27 Jan 2012 13:07:38 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> In-Reply-To: <82r4ylqr4q.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:13:05 -0000 Florian, On 01/27/2012 09:14 AM, Florian Weimer wrote: >> On 01/27/2012 08:36 AM, Florian Weimer wrote: >>> And I see no functional difference between the gateway and the host >>> generating the fragment ID, except that the latter approach seems to >>> require network-wide software updates currently. >> >> Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by >> inserting a Fragment Header in subsequent packets, or what? (last time I >> checked, I think this was the case) > > There are existing deployments which effectively filter ICMPv6 traffic. They should know better.. what can I say? > Some of them do so explicitly, others simply to do not broadcast > incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to > make this work with behind a per-packet load balancer). Naked host > behavior does not matter in such scenarios. How does this make a special case for atomic fragments? If they do this, they also break PMTUD -- not just the generation of atomic fragments. > As soon as IPv6 traffic levels increase, all busy UDP sources will stop > generating atomic fragments reliably because at the time of retry, the > fact that an atomic fragment is required has expired from the > destination cache (if there is one in the first place, that is). > That's why Mark proposes to send atomic fragments unconditionally > and *that* is known to break stuff for sure. Regarding Mark's proposal, yes, some stacks need to patch their bugs (this was required by RFC 2460, not by a brand new RFC). >> In any, please note the difference between *accepting* atomic fragments, >> generating ICMPv6 PTB when the MTU of the constricting link is < 1280, >> and reacting to ICMPv6 PTB by generating atomic fragments. > > True, but why would it be important to accept atomic fragments, when the > system as a whole does not actually generate them properly? So that you have only one bug instead of two? No kidding, as noted a a while ago, you can process atomic fragments as securely as non-fragmented traffic. So I don't understand why you're making a big deal. -- This is the sort of thing that, since you can do the right thing easily with no security implications, you simply do it. > I'm worried that we're imposing updates on significant parts of the > network to address an issue that could also be fixed locally, > maintaining full interoperability with the rest of the network as it > exists now. Not sure what you mean by "fixes locally". (That said, the cat is out of the bag, already -- there's stuff that depends on this). That said, I wouldn't call this an "update". I'd call this a bug fix... and you fix many of these, so... what's the big deal? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Fri Jan 27 08:43:22 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48821F85E3 for ; Fri, 27 Jan 2012 08:43:22 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5jAdk9EcFWX for ; Fri, 27 Jan 2012 08:43:21 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 58B9521F85AF for ; Fri, 27 Jan 2012 08:43:16 -0800 (PST) Received: from [24.232.158.65] (helo=[192.168.88.248]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqotM-0008Az-S5; Fri, 27 Jan 2012 17:43:13 +0100 Message-ID: <4F22CE8C.2030107@si6networks.com> Date: Fri, 27 Jan 2012 13:19:24 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:43:22 -0000 On 01/27/2012 08:13 AM, Philip Homburg wrote: > Given the current trends, just a random number would be good enough. But the > old RFCs assumed that a sequence number was used to maintain uniqueness. May I ask what the "current trends" are? And no, just a random number is not good enough, particularly if you're talking about the IPv4 IP ID. (talk about collisions). (For IPv6, I suggest that you talk with davem@, which noted that we would not even want such a scheme for the IPv6 (i.e., 32-bit long) fragment ID). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From pch-b29AA871B@u-1.phicoh.com Fri Jan 27 09:36:44 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFB921F861A for ; Fri, 27 Jan 2012 09:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.407 X-Spam-Level: X-Spam-Status: No, score=-8.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZqvk-lufeVz for ; Fri, 27 Jan 2012 09:36:44 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4021F860B for ; Fri, 27 Jan 2012 09:36:43 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rqpit-0001jbC; Fri, 27 Jan 2012 18:36:27 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> In-reply-to: Your message of "Fri, 27 Jan 2012 13:19:24 -0300 ." <4F22CE8C.2030107@si6networks.com> Date: Fri, 27 Jan 2012 18:36:26 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 17:36:44 -0000 In your letter dated Fri, 27 Jan 2012 13:19:24 -0300 you wrote: >On 01/27/2012 08:13 AM, Philip Homburg wrote: >> Given the current trends, just a random number would be good enough. But the >> old RFCs assumed that a sequence number was used to maintain uniqueness. > >May I ask what the "current trends" are? And no, just a random number is >not good enough, particularly if you're talking about the IPv4 IP ID. >(talk about collisions). > >(For IPv6, I suggest that you talk with davem@, which noted that we >would not even want such a scheme for the IPv6 (i.e., 32-bit long) >fragment ID). For avoiding collissions, a single global counter is optimal. To avoid traffic analysis, a counter per destination is proposed. But how do you initialize that counter? From a random number. So any system that is too busy to keep destination cache entries for a long time will effectively send fragments with a random number. Now for IPv4, to get a reasonable chance of a collision, you have to have 256 fragmented packets in flight at the same time between a source/destination pair (ignoring protocol for the moment). Then you also need those packets to either suffer the loss of a fragment (all at the same time) or you need sufficient reordering that 256 packets somehow overlap during fragmentation. And when that happens, the normal TCP/UDP checksum is likely to throw out all but one in 65535 packets. And anythingh encrypted will just see a loss of a connection. To improve on that, an IPv6 fragment header has to have a counter in the lower 16 bits (the part that gets copied to the IPv4 header). That means that if the sender deletes to destination cache entry before all unassembled packets have been deleted or in flight packet have arrive, you are back in trouble. And that also assumes that the IPv4/IPv6 translator will never map two IPv6 source addresses to one IPv4 source address, because then the whole thing also falls over. So, as far as I can tell, the risk that something goes wrong if you don't send the fragment header is something very close to zero. The chance that sending the fragment header is actually beneficial is also very small. From fgont@si6networks.com Fri Jan 27 11:18:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE20121F8604 for ; Fri, 27 Jan 2012 11:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.984, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMeUzsYmpr2m for ; Fri, 27 Jan 2012 11:18:39 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1B40F21F85C0 for ; Fri, 27 Jan 2012 11:18:39 -0800 (PST) Received: from [190.48.238.5] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RqrJj-0000hF-H9; Fri, 27 Jan 2012 20:18:36 +0100 Message-ID: <4F22F884.1080101@si6networks.com> Date: Fri, 27 Jan 2012 16:18:28 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:18:40 -0000 Hi, Philip, On 01/27/2012 02:36 PM, Philip Homburg wrote: >> (For IPv6, I suggest that you talk with davem@, which noted that we >> would not even want such a scheme for the IPv6 (i.e., 32-bit long) >> fragment ID). > > For avoiding collissions, a single global counter is optimal. To avoid traffic > analysis, a counter per destination is proposed. But how do you initialize > that counter? From a random number. > > So any system that is too busy to keep destination cache entries for a long > time will effectively send fragments with a random number. There are always tradeoffs in the IP-ID generation algorithms. If you don't like any of the forementioned approaches, you may have a set of counters (say, 1024, 2048, or 65K, if you will), using an approach similar to that of algorithm 2 in my flowlabel I-D. Note, however, that if you cannot maintain a destinations cache, you may also have issues with PMTUD, etc. I'd argue that the scenario that you're describing, while not uncommon, probably does not apply for the general case. So it would not be unfair to have, at least for those scenarios, some specialized policy such as the one described above. > Now for IPv4, to get a reasonable chance of a collision, you have to have > 256 fragmented packets in flight at the same time between a source/destination > pair (ignoring protocol for the moment). You need to have sufficient packet loss. at which point, the IP ID gets trashed. > Then you also need those packets to > either suffer the loss of a fragment (all at the same time) or you need > sufficient reordering that 256 packets somehow overlap during fragmentation. Not sure what you mean. As long as one packet gets lost, the IP ID space will get trashed. If another packet reuses the same ID, then it's very likely that the reassembly process will fail, and it may be even possible that some of the legitimate fragments remain in the fragment reassembly buffer, trashing the IP ID space. > To improve on that, an IPv6 fragment header has to have a counter in the lower > 16 bits (the part that gets copied to the IPv4 header). > > That means that if the sender deletes to destination cache entry before all > unassembled packets have been deleted or in flight packet have arrive, you are > back in trouble. Well, yes, there's no such a thing as a "free lunch". > So, as far as I can tell, the risk that something goes wrong if you don't send > the fragment header is something very close to zero. The chance that sending > the fragment header is actually beneficial is also very small. So... you're essentially relying on guesswork because: a) You consider that requiring the translator to send an ICMPv6 PTB is way too much, (which is already a requirement for PMTUD), and, b) You consider that processing atomic fragments as described in draft-gont-6man-ipv6-atomic-fragment is... what? I'd rather patch what needs to be patched (see OpenBSD's patch for the atomic-fragments thing), and be done with it, rather than relying on guesswork/assumptions. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From pch-b29AA871B@u-1.phicoh.com Fri Jan 27 13:08:21 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D04B21F869D for ; Fri, 27 Jan 2012 13:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.435 X-Spam-Level: X-Spam-Status: No, score=-8.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+5t4EF3+oFU for ; Fri, 27 Jan 2012 13:08:20 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id CE28721F869C for ; Fri, 27 Jan 2012 13:08:19 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rqt1p-0001ivC; Fri, 27 Jan 2012 22:08:13 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> <4F22F884.1080101@si6networks.com> In-reply-to: Your message of "Fri, 27 Jan 2012 16:18:28 -0300 ." <4F22F884.1080101@si6networks.com> Date: Fri, 27 Jan 2012 22:08:12 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:08:21 -0000 In your letter dated Fri, 27 Jan 2012 16:18:28 -0300 you wrote: >Hi, Philip, > >On 01/27/2012 02:36 PM, Philip Homburg wrote: >>> (For IPv6, I suggest that you talk with davem@, which noted that we >>> would not even want such a scheme for the IPv6 (i.e., 32-bit long) >>> fragment ID). >> >> For avoiding collissions, a single global counter is optimal. To avoid traff >ic >> analysis, a counter per destination is proposed. But how do you initialize >> that counter? From a random number. >> >> So any system that is too busy to keep destination cache entries for a long >> time will effectively send fragments with a random number. > >There are always tradeoffs in the IP-ID generation algorithms. If you >don't like any of the forementioned approaches, you may have a set of >counters (say, 1024, 2048, or 65K, if you will), using an approach >similar to that of algorithm 2 in my flowlabel I-D. I'm not really keeping track of flowlabel stuff. Do you have a more specific reference? draft-gont-6man-flowlabel-security-02 doesn't seem to have an algorithm 2. And I couldn't find any other flowlabel draft with your name on it. >Note, however, that if you cannot maintain a destinations cache, you may >also have issues with PMTUD, etc. > >I'd argue that the scenario that you're describing, while not uncommon, >probably does not apply for the general case. So it would not be unfair >to have, at least for those scenarios, some specialized policy such as >the one described above. PMTUD is just a mess. For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on pmtud gives a bad user experience. For IPv6, the situation is not any better. But there is new option, servers may simply set their mtu to 1280 and no more pmtu problems. PMTU blackhole detection is surprisingly uncommon. IPv6 also lacks NAT, so either CPEs will have to do mss clamping on the fly or lots of servers will end up with just setting the mtu to 1280. >> Then you also need those packets to >> either suffer the loss of a fragment (all at the same time) or you need >> sufficient reordering that 256 packets somehow overlap during fragmentation. > >Not sure what you mean. As long as one packet gets lost, the IP ID space >will get trashed. If another packet reuses the same ID, then it's very >likely that the reassembly process will fail, and it may be even >possible that some of the legitimate fragments remain in the fragment >reassembly buffer, trashing the IP ID space. With random IDs, every packet that arrives has a 1/65536 chance of colliding with a packet that is awaiting reassembly. Total chance depends on the reassembly timeout and the packets rate. Needless to say this only applies to IPv4 hosts that are behind a link smaller than 1280. >> So, as far as I can tell, the risk that something goes wrong if you don't se >nd >> the fragment header is something very close to zero. The chance that sending >> the fragment header is actually beneficial is also very small. > >So... you're essentially relying on guesswork because: > >a) You consider that requiring the translator to send an ICMPv6 PTB is >way too much, (which is already a requirement for PMTUD), and, I don't particularly care about the translators. >b) You consider that processing atomic fragments as described in >draft-gont-6man-ipv6-atomic-fragment is... what? One option is that hosts behind such translators will have mss clamping because PMTU doesn't work anyhow. This is very likely, because you need that on the current IPv4 network. Most likely many servers will just break PMTU for this case, which requires translators to just insert a random ID and forward the packet. Effectively changing the protocol. However, there is a small chance that server operators will actually follow the RFC and start always including fragment headers. And that's not only very annoying, but also an enormous waste of resources. Effectively, we are saying that it was an enormous mistake to not include fragmentation in the IPv6 header and that we removed it from the routers. From fgont@si6networks.com Fri Jan 27 14:14:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C621F85F0 for ; Fri, 27 Jan 2012 14:14:10 -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=-2.599, J_CHICKENPOX_31=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svvYrBCdVdHL for ; Fri, 27 Jan 2012 14:14:09 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1789C21F85EA for ; Fri, 27 Jan 2012 14:14:09 -0800 (PST) Received: from [2001:5c0:1000:a::16f] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rqu3X-0001yD-RO; Fri, 27 Jan 2012 23:14:04 +0100 Message-ID: <4F23219A.10101@si6networks.com> Date: Fri, 27 Jan 2012 19:13:46 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Philip Homburg Subject: Fragment ID generation and Flow Label generation (was: Re: Fragmentation-related security issues) References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> <4F22F884.1080101@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:14:10 -0000 On 01/27/2012 06:08 PM, Philip Homburg wrote: >>> So any system that is too busy to keep destination cache entries for a long >>> time will effectively send fragments with a random number. >> >> There are always tradeoffs in the IP-ID generation algorithms. If you >> don't like any of the forementioned approaches, you may have a set of >> counters (say, 1024, 2048, or 65K, if you will), using an approach >> similar to that of algorithm 2 in my flowlabel I-D. > > I'm not really keeping track of flowlabel stuff. Do you have a more specific > reference? draft-gont-6man-flowlabel-security-02 doesn't seem to have an > algorithm 2. And I couldn't find any other flowlabel draft with your name on > it. Please see pages 9-11 of . Page 11 contains a sample output of the double-hash algorithm, which you can compare with the sample output of algorithm #1 in page 9. If you wanted to keep say, 1K or 65K counters (as a tradeoff between security and "avoiding excessive state"), you could select the FL as: Flow Label = table[G(Source Address, Destination Address, Secret Key1)] and use the following pseudo code: /* Initialization at system boot time */ for(i = 0; i < TABLE_LENGTH; i++) table[i] = random(); /* Flow Label selection function */ index = G(local_IP, remote_IP, secret_key2); count = 1048576; do { flowlabel = table[index] % 1048576; table[index]++; if(three-tuple is unique) return flowlabel; count--; } while (count > 0); /* Set the Flow Label to 0 if there is no unused Flow Label */ return 0; You could even include only the remote prefix (rather than the full remote IPv6 address) in the hash function, such that you can reduce the attacker chances of searching the entire "counter" space. >> I'd argue that the scenario that you're describing, while not uncommon, >> probably does not apply for the general case. So it would not be unfair >> to have, at least for those scenarios, some specialized policy such as >> the one described above. > > PMTUD is just a mess. > > For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on > pmtud gives a bad user experience. Since IPv4 MTUs can be as low as 296, and since I doubt you clamp the MSS to such a low value, you still rely on PMTUD. (Hopefully you system imlements PMTUD + PLPMTUD for blackhole detection). > For IPv6, the situation is not any better. But there is new option, servers > may simply set their mtu to 1280 and no more pmtu problems. > > PMTU blackhole detection is surprisingly uncommon. It is implemented in OpenBSD, I recall it bein implemented in Windows... so I don't think it is uncommon. > IPv6 also lacks NAT, Well, it doesn't: >> Not sure what you mean. As long as one packet gets lost, the IP ID space >> will get trashed. If another packet reuses the same ID, then it's very >> likely that the reassembly process will fail, and it may be even >> possible that some of the legitimate fragments remain in the fragment >> reassembly buffer, trashing the IP ID space. > > With random IDs, every packet that arrives has a 1/65536 chance of colliding > with a packet that is awaiting reassembly. Total chance depends on the > reassembly timeout and the packets rate. And most importantly, the loss rate. Add a bad combination of reassembly timeout + loss rate + data rate, and you're toast. See e.g. >>> So, as far as I can tell, the risk that something goes wrong if you don't se >> nd >>> the fragment header is something very close to zero. The chance that sending >>> the fragment header is actually beneficial is also very small. >> >> So... you're essentially relying on guesswork because: >> >> a) You consider that requiring the translator to send an ICMPv6 PTB is >> way too much, (which is already a requirement for PMTUD), and, > > I don't particularly care about the translators. There are other sources of this traffic. It has been reported on the list that this traffic has been found on the wild. Since such traffic is already there, you need to support atomic fragments. And if you're going to support it (which you should), the then IMO the most sensible way to do it is as indicated in the atomic fragments I-D. >> b) You consider that processing atomic fragments as described in >> draft-gont-6man-ipv6-atomic-fragment is... what? > > One option is that hosts behind such translators will have mss clamping because > PMTU doesn't work anyhow. This is very likely, because you need that on the > current IPv4 network. As noted above: 1) Why value would you use for clamping? (if it's anything >296, then it doesn't relieve you from relying on PMTUD) 2) As noted, there are other sources of atomic fragments. > Effectively, we are saying that it was an enormous mistake to not include > fragmentation in the IPv6 header and that we removed it from the routers. That's a completely different discussion. Me, I'm just trying to improve what we have (which does not necessarily mean that I love the current state of affairs). Even if you wanted to, it's probably way too late to start from a clean slate. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From dthaler@microsoft.com Fri Jan 27 17:23:23 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026ED21F84CF for ; Fri, 27 Jan 2012 17:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.979 X-Spam-Level: X-Spam-Status: No, score=-103.979 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6Mfc5pxgC7R for ; Fri, 27 Jan 2012 17:23:22 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 14B0521F84C3 for ; Fri, 27 Jan 2012 17:23:21 -0800 (PST) Received: from mail71-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Sat, 28 Jan 2012 01:23:20 +0000 Received: from mail71-db3 (localhost [127.0.0.1]) by mail71-db3-R.bigfish.com (Postfix) with ESMTP id BB92F160609; Sat, 28 Jan 2012 01:23:20 +0000 (UTC) X-SpamScore: -12 X-BigFish: VS-12(zz179dN1432Nzz1202hzzz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail71-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail71-db3 (localhost.localdomain [127.0.0.1]) by mail71-db3 (MessageSwitch) id 132771379920231_7707; Sat, 28 Jan 2012 01:23:19 +0000 (UTC) Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.237]) by mail71-db3.bigfish.com (Postfix) with ESMTP id E8FD7A0045; Sat, 28 Jan 2012 01:23:18 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 28 Jan 2012 01:23:16 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.247.5; Fri, 27 Jan 2012 17:23:13 -0800 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.234]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 17:23:13 -0800 From: Dave Thaler To: Chris Grundemann , Brian E Carpenter Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt Thread-Topic: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt Thread-Index: AQHMmvx1vO8I87vUo0m73gUxdiNcXZXd39qAgAAf8wCAAAn2gIAAFZKAgAAYZICAABHNAIAABeSAgEMv5BA= Date: Sat, 28 Jan 2012 01:23:13 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Bob Hinden , Brian Haberman , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 01:23:23 -0000 > >> Hmm sorry for being unclear, the technical part looked okay as far as > >> I could tell, but as the quoted words from you, it will probably be > >> more confusing to have two documents where the last one update/change > >> the first one. Would be much better to have just one > >> replacing/updating the old one. > > > > That was my first thought, but then I realised it would cause a lot of > > delay, and I think getting these changes deployed is quite urgent. >=20 > I must agree, there is certainly an urgent need to fix the problems in th= e current > RFC 3484, particularly around the handling of ULAs, etc. > For one example; I am currently working on sorting out proper IPv6 suppor= t in > UPnP and DLNA (targeting CE) and we have (effectively) nothing to point t= o for > dynamic source address selection procedures. > Since there appears to be consensus on the technical changes, is there a = way to > make the needed editorial changes and then advance to IETF last call (or = a > second WG last call at least)? Resurrecting this thread in the hopes of resurrecting some energy on this d= raft... It is not correct that we have consensus on the technical changes, since I raised a number of technical issues in my review of the document (and since only Brian and I reviewed, that's 50% of reviewers :) That said, I think it would be easy to get consensus since I made specific recommendations that I don't think should be controversial. But in any ca= se, this would definitely need a second WGLC. -Dave From fweimer@bfk.de Sat Jan 28 06:26:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B6A21F84FD for ; Sat, 28 Jan 2012 06:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwSxHe013zOA for ; Sat, 28 Jan 2012 06:26:58 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38221F84FC for ; Sat, 28 Jan 2012 06:26:58 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rr9F1-000855-IV; Sat, 28 Jan 2012 14:26:55 +0000 Received: by bfk.de with local id 1Rr9F1-0005VZ-ED; Sat, 28 Jan 2012 14:26:55 +0000 From: Florian Weimer To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> Date: Sat, 28 Jan 2012 14:26:55 +0000 In-Reply-To: <4F22CBCA.5040106@si6networks.com> (Fernando Gont's message of "Fri, 27 Jan 2012 13:07:38 -0300") Message-ID: <824nvfq4wg.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipv6@ietf.org" , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2012 14:26:59 -0000 * Fernando Gont: >> There are existing deployments which effectively filter ICMPv6 traffic. > > They should know better.. what can I say? These people generally know what they are doing. >> Some of them do so explicitly, others simply to do not broadcast >> incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to >> make this work with behind a per-packet load balancer). Naked host >> behavior does not matter in such scenarios. > > How does this make a special case for atomic fragments? If they do this, > they also break PMTUD -- not just the generation of atomic fragments. Currently, you can set DF=3D0 on IPv4 packets you sent, and fragment IPv6 at 1280 bytes. Then you don't need to implement PMTUD. If you want to deal with atomic fragments in the same way, you have to add a fragment header to all outgoing packets smaller than 1280 bytes, creating atomic fragments. However, this doesn't work on the current network because there are nodes which cannot process atomic fragments, and you really, really need to support them. Generating conforming packets just isn't sufficient here, the recipient must actually be able to process them. You can work around that by broadcasting incoming ICMP packets internally and provision a large enough destination cache on every node, as I said before. But this is an insane amount of complexity for very little gain. >> True, but why would it be important to accept atomic fragments, when the >> system as a whole does not actually generate them properly? > > So that you have only one bug instead of two? Well, I think the gateway issue is actually fixable (because it's local). Pervasive atomic fragment support requires kernel, client and server software updates in a certain order, something which is unlikely to happen soon. So the gateways will need those local workarounds anyway, otherwise they will have trouble using DNS over IPv6. > No kidding, as noted a a while ago, you can process atomic fragments as > securely as non-fragmented traffic. Except when you need to drop traffic with extension headers. From time to time, there are compelling reasons to do this. > That said, I wouldn't call this an "update". I'd call this a bug fix... > and you fix many of these, so... what's the big deal? I think it's misleading to publish an RFC which implicitly suggests that atomic fragments work on the current network, or somehow can be made to work. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fgont@si6networks.com Sat Jan 28 16:02:32 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88D521F8523 for ; Sat, 28 Jan 2012 16:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1sOzmV2-FqA for ; Sat, 28 Jan 2012 16:02:32 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 057CA21F8516 for ; Sat, 28 Jan 2012 16:02:31 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.110]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RrIDy-0005vR-Sh; Sun, 29 Jan 2012 01:02:27 +0100 Message-ID: <4F23AAFC.6010404@si6networks.com> Date: Sat, 28 Jan 2012 04:59:56 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragment ID generation and Flow Label generation References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> <4F22F884.1080101@si6networks.com> <4F23219A.10101@si6networks.com> In-Reply-To: <4F23219A.10101@si6networks.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 00:02:33 -0000 On 01/27/2012 07:13 PM, Fernando Gont wrote: > On 01/27/2012 06:08 PM, Philip Homburg wrote: >>>> So any system that is too busy to keep destination cache entries for a long >>>> time will effectively send fragments with a random number. >>> >>> There are always tradeoffs in the IP-ID generation algorithms. If you >>> don't like any of the forementioned approaches, you may have a set of >>> counters (say, 1024, 2048, or 65K, if you will), using an approach >>> similar to that of algorithm 2 in my flowlabel I-D. >> >> I'm not really keeping track of flowlabel stuff. Do you have a more specific >> reference? draft-gont-6man-flowlabel-security-02 doesn't seem to have an >> algorithm 2. And I couldn't find any other flowlabel draft with your name on >> it. > > Please see pages 9-11 of > . > Page 11 contains a sample output of the double-hash algorithm, which you > can compare with the sample output of algorithm #1 in page 9. > > If you wanted to keep say, 1K or 65K counters (as a tradeoff between > security and "avoiding excessive state"), you could select the FL as: Let me clarify this a bit, and add a few more bits... With the hash-based approach, you essentially have two elements: the hash function, and the counter. The hash function adds the randomness, while the counter produces the monotonically increasing sequence. >From a FL frequency-reuse perspective, you'd have one counter per destination, such that if flow #1 gets, say, FL 1000, flow #2 will get 1001, and so on. This approach is possible to implement if you keep the counter in the Destinations Cache (which is the obvious place to store it, since there's one Destinations Cache entry per destination IPv6 address). On the other extreme, you might have a single global counter (which you'd keep somewhere in the IPv6 code, but not in any particular Destination Cache entry. The two problems with this approach are: 1) If you keep a single counter, an attacker could possibly count the number of new flaws established by a target system 2) Some FL values will be unnecessarily skipped (see the sample output for algorithm #1 in draft-gont-6man-flowlabel-security) A middle-ground would be to have an array of counters (neither one global counter, nor one counter per destination). -- This is algorithm #2 in the flowlabel-security I-D. With this algorithm, even if you were to discard entries from the Destinations Cache, it would still work (the counters are kept in the IPv6 code, but not in any Destinations Cache entry -- and the counters are shared between different flows). A similar approach could be implemented for the generation of Fragment Identification values. Thus, even if you needed to empty the Destinations Cache, you'd still have the benefit that the algorithm: * Makes the IDs (either FL or Fragment ID) difficult to guess by an off-path attacker * Minimize the reuse frequency of the corresponding IDs. Hope this one helps to clarify things a bit... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sat Jan 28 16:03:17 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934821F85AA for ; Sat, 28 Jan 2012 16:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.346 X-Spam-Level: X-Spam-Status: No, score=0.346 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, FRT_STOCK2=3.988] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CekxB9jXD+N for ; Sat, 28 Jan 2012 16:03:17 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id B94F421F85A8 for ; Sat, 28 Jan 2012 16:03:16 -0800 (PST) Received: from [186.137.77.114] (helo=[192.168.1.110]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RrIE9-0005vW-PR; Sun, 29 Jan 2012 01:03:14 +0100 Message-ID: <4F24879E.8000002@si6networks.com> Date: Sat, 28 Jan 2012 20:41:18 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> In-Reply-To: <824nvfq4wg.fsf@mid.bfk.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Philip Homburg X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 00:03:17 -0000 Florian, On 01/28/2012 11:26 AM, Florian Weimer wrote: >>> There are existing deployments which effectively filter ICMPv6 traffic. >> >> They should know better.. what can I say? > > These people generally know what they are doing. TCP relies on PMTUD, so how can you possibly state that "they know what they are doing"? Those are generally the same people that broke IPv4's PMTUD, that lead to non-working 6to4 and Teredo, etc. I have seen quite a few of those hard-to-debug issues which ended up in the culprits removing the filters that they had. >>> Some of them do so explicitly, others simply to do not broadcast >>> incoming IPv6 ICMP traffic to all cluster nodes (or whatever it takes to >>> make this work with behind a per-packet load balancer). Naked host >>> behavior does not matter in such scenarios. >> >> How does this make a special case for atomic fragments? If they do this, >> they also break PMTUD -- not just the generation of atomic fragments. > > Currently, you can set DF=0 on IPv4 packets you sent, and fragment IPv6 > at 1280 bytes. Then you don't need to implement PMTUD. > > If you want to deal with atomic fragments in the same way, you have to > add a fragment header to all outgoing packets smaller than 1280 bytes, > creating atomic fragments. However, this doesn't work on the current > network because there are nodes which cannot process atomic fragments, There are many bugs in current IPv6 implementations, and there are many more to be found, because most of them are still very immature. If you take the stance of "we know of a buggy implementation that does not support this, and hence this mechanism is forbidden", I wonder where we'd end up. Fix the bug, and move on. > You can work around that by broadcasting incoming ICMP packets > internally and provision a large enough destination cache on every node, > as I said before. B Or just use the setsockopt() that Mark proposed if you're not going to rely on PMTUD. >>> True, but why would it be important to accept atomic fragments, when the >>> system as a whole does not actually generate them properly? >> >> So that you have only one bug instead of two? > > Well, I think the gateway issue is actually fixable (because it's > local). Pervasive atomic fragment support requires kernel, client and > server software updates in a certain order, something which is unlikely > to happen soon. It is unlikely to happen as long as people invest more time in arguing in favour of bugs, rather than in fixing them. Look at OpenBSD's patch. They did it in a couple of days. That said, nobody is *introducing* atomic fragments.They should have been supported for more than 15 years, and there is other stuff (mentioned by Dan Wing at others) that would break without this. My I-D is about improving their handling... not about introducing support of atomic fragments to the IPv6 world. >> No kidding, as noted a a while ago, you can process atomic fragments as >> securely as non-fragmented traffic. > > Except when you need to drop traffic with extension headers. From time > to time, there are compelling reasons to do this. There are times in which you also need to drop TCP traffic. SHould we ban TCP, too? >> That said, I wouldn't call this an "update". I'd call this a bug fix... >> and you fix many of these, so... what's the big deal? > > I think it's misleading to publish an RFC which implicitly suggests that > atomic fragments work on the current network, or somehow can be made to > work. It doesn't imply anything. It just improves the handling of such packets when compared with the current specs. That's it. If you think the document should note that some systems do not support this packets, or the like, I'd have no problem in doing so. For instance, I will try to include a list of working vs. broken implementations in the next rev of the I-D, and also note which ones implement the proposed behaviour. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Sun Jan 29 11:46:26 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7B221F8570 for ; Sun, 29 Jan 2012 11:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P7eGuuwcpMA for ; Sun, 29 Jan 2012 11:46:26 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C9F2821F852C for ; Sun, 29 Jan 2012 11:46:25 -0800 (PST) Received: by eekc1 with SMTP id c1so1164493eek.31 for ; Sun, 29 Jan 2012 11:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vMPy0cxjAoeg6xXdrYNCNWd+FeVfr1D3SQZS2asUeVs=; b=bOD5/Z3a4SvdYPLRMQ/o/G5nkZpHjF+pGn4p8Phb+zkzRraQdLYAnMGnf10dDlPGrI Ao7644RRn2F/2CdZt48Z3nC64gtfF2yRq5di5f8ThGEkgdIAP85biSO9680a23AUf9SE NrDr391OuysdZ7R55uGLWsbhECWErcQ+GX1is= Received: by 10.14.13.129 with SMTP id b1mr1702385eeb.41.1327866385038; Sun, 29 Jan 2012 11:46:25 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id t11sm35668269eea.10.2012.01.29.11.46.22 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 11:46:24 -0800 (PST) Message-ID: <4F25A206.1070701@gmail.com> Date: Mon, 30 Jan 2012 08:46:14 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragment ID generation and Flow Label generation References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> <4F22F884.1080101@si6networks.com> <4F23219A.10101@si6networks.com> <4F23AAFC.6010404@si6networks.com> In-Reply-To: <4F23AAFC.6010404@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Philip Homburg , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 19:46:26 -0000 On 2012-01-28 20:59, Fernando Gont wrote: ... > A similar approach could be implemented for the generation of Fragment > Identification values. > > Thus, even if you needed to empty the Destinations Cache, you'd still > have the benefit that the algorithm: > * Makes the IDs (either FL or Fragment ID) difficult to guess by an > off-path attacker > * Minimize the reuse frequency of the corresponding IDs. I think it's a mistake to draw a strong analogy between the flow label and the fragment ID. When the flow label is used for any form of load distribution, it really doesn't matter if occasional flows share the same label value, as long as this is statistially rare. It just means that the two flows might happen to follow the same path - so what? Thus, a completely stateless algorithm is fine and the counter brings no benefit. OTOH surely we need to completely avoid overlapping fragment IDs. Brian From brian.e.carpenter@gmail.com Sun Jan 29 14:30:58 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA9121F84F2 for ; Sun, 29 Jan 2012 14:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9prHhhDIF0IN for ; Sun, 29 Jan 2012 14:30:58 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C683421F84EF for ; Sun, 29 Jan 2012 14:30:57 -0800 (PST) Received: by eaai12 with SMTP id i12so615360eaa.31 for ; Sun, 29 Jan 2012 14:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UFBqSKhiipdLiRBHnRz8lWpCbKBxpGTYiXhU2sVcIWw=; b=MKiWs+1veMZ26uNFfnJd/0NxZV5VerK+aJ/LEqCVKcJKnCvXx8tHdyfjmHhCSE15eg AYIp+wBT2VjKEiBgTA2Irxpdv6EEI1PndoGYdgIvL/Iat8wWKYw5iISVp8vj2AInDEZj u/r7HV2uBrSErM60rsFELuT3WkbbKqakc+E38= Received: by 10.213.113.138 with SMTP id a10mr828586ebq.25.1327876256955; Sun, 29 Jan 2012 14:30:56 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n56sm64350190eeh.6.2012.01.29.14.30.52 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 14:30:56 -0800 (PST) Message-ID: <4F25C895.1090500@gmail.com> Date: Mon, 30 Jan 2012 11:30:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Thaler Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Brian Haberman , Bob Hinden X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 22:30:58 -0000 On 2012-01-28 14:23, Dave Thaler wrote: ... > That said, I think it would be easy to get consensus since I made specific > recommendations that I don't think should be controversial. But in any case, > this would definitely need a second WGLC. True, but let's do it, since the market really needs this update. Brian From brian.e.carpenter@gmail.com Sun Jan 29 14:37:34 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF32021F8474 for ; Sun, 29 Jan 2012 14:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.271 X-Spam-Level: X-Spam-Status: No, score=-103.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo1CXJaNUHio for ; Sun, 29 Jan 2012 14:37:33 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 349FC21F8470 for ; Sun, 29 Jan 2012 14:37:33 -0800 (PST) Received: by eaai12 with SMTP id i12so616370eaa.31 for ; Sun, 29 Jan 2012 14:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lNaG2NkCBqZ6gPdY5HMWT2OMaBq3PiH5EOwE7USihXg=; b=fdgu4lLcRkge9KBsH2LzHzEjubwbQWwZjIacKSnK71hXb3ieNIOXVFHuB+GYjIGLQh vcxDsbnlkXiN6KKDtQONOPVo2pFtVYlNYKsiO+odmv4C1/AadUrmHrmXmGNLP4j3mref M6m4glrac4/xzvzaSSVQcCp6wblqKb31OXdOs= Received: by 10.213.22.204 with SMTP id o12mr2338351ebb.1.1327876652423; Sun, 29 Jan 2012 14:37:32 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y54sm64388297eef.8.2012.01.29.14.37.30 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 14:37:32 -0800 (PST) Message-ID: <4F25CA23.90706@gmail.com> Date: Mon, 30 Jan 2012 11:37:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6man Subject: Re: Reviews requested: draft-carpenter-6man-uri-zoneid-00.txt References: <4F03B818.6000100@gmail.com> In-Reply-To: <4F03B818.6000100@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 22:37:34 -0000 Hi, I've only seen one comment on this question. Any more, or should the authors just decide? Regards Brian Carpenter On 2012-01-04 15:23, Brian E Carpenter wrote: > Representing IPv6 Zone Identifiers in Uniform Resource Identifiers > > We'd like feedback on this. In particular, which of the two options > proposed do people prefer? > > OPTION 1: > > The existing syntax of IPv6address is extended by adding a specific > option for the case of link-local addresses. > > OPTION 2: > > The existing syntax of IPv6address is retained, and a zone identifier > may be added optionally to any literal address. This allows > flexibility for unknown future uses. > > - Brian & Bob > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-6man-uri-zoneid-00.txt > Date: Tue, 06 Dec 2011 17:27:00 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Representing IPv6 Zone Identifiers in Uniform Resource Identifiers > Author(s) : Brian Carpenter > Robert M. Hinden > Filename : draft-carpenter-6man-uri-zoneid-00.txt > Pages : 6 > Date : 2011-12-06 > > This document describes how the Zone Identifier of an IPv6 scoped > address can be represented in a Uniform Resource Identifier that > includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-6man-uri-zoneid-00.txt > > > From brian.e.carpenter@gmail.com Sun Jan 29 19:56:10 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22AC21F84F7 for ; Sun, 29 Jan 2012 19:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.815 X-Spam-Level: X-Spam-Status: No, score=-101.815 tagged_above=-999 required=5 tests=[AWL=-1.716, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_31=0.6, MANGLED_OFF=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IE9ufotNdCPl for ; Sun, 29 Jan 2012 19:56:10 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CABD521F84F5 for ; Sun, 29 Jan 2012 19:56:09 -0800 (PST) Received: by eekc1 with SMTP id c1so1237030eek.31 for ; Sun, 29 Jan 2012 19:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+6uKlqK1wQ9a59vrRXo34zCxIggN4zhnlYx04P9HHx8=; b=lx06wVRk4X/Z/5VyfuaWZW5Mn+T1QIUDSV6Wfo1HK/NRToDMoV+YRCvqiz79A5Jdbm +/pHN8HCAg9z76mJ6KzCectW0ml1W5gX9xhIFYf+0+bxIN3Ni8+sxtekX2qwwiZy8hMp yIzGebsNJ3tn7BNj7kA2tWzl7nIfcpzC/3CYc= Received: by 10.213.33.8 with SMTP id f8mr2444516ebd.119.1327895768986; Sun, 29 Jan 2012 19:56:08 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x4sm67267960eeb.4.2012.01.29.19.56.05 (version=SSLv3 cipher=OTHER); Sun, 29 Jan 2012 19:56:08 -0800 (PST) Message-ID: <4F2614CE.1000808@gmail.com> Date: Mon, 30 Jan 2012 16:55:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> <4F1FD701.9050402@si6networks.com> <4F200713.6070609@innovationslab.net> <4F200CB5.4080907@si6networks.com> <4F20614E.9000102@gmail.com> <4F2130D4.4010707@si6networks.com> In-Reply-To: <4F2130D4.4010707@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 03:56:10 -0000 Fernando, On 2012-01-26 23:54, Fernando Gont wrote: > Hi, Brian, > > On 01/25/2012 05:08 PM, Brian E Carpenter wrote: >>> Agreed. The point I'm trying to make is that I do not see what the >>> attacker would gain from guessing a label that's not in use yet. For >>> instance, if he were to send packets with that forged label, the spoofed >>> traffic might not event "compete" with any existing traffic. >> One case that I'm thinking of specifically is if the attacker also knows >> the load balancing algorithm in use, > > One should expect the attacker to know the load-balancing algorithm, but > not the parameters with which it operates. > > If the attacker knows all of these things (algorithm+parameters), then > *that* is where the flaw is (assuming having the attacker play with > load-balancing is a concern, of course). > > > >> and in particular how it interacts >> with the flow label, then there might be a way to bias the load balancing >> and orchestrate a DOS SYN attack on a particular server. > > Not sure what you mean. Are you arguing that in this case the flow-label > would be used for *server* load-balancing? Yes (draft-carpenter-v6ops-label-balance) but there could be a similar argument for ECMP or LAG, where "the worst an attacker could do against ECMP or LAG is attempt to selectively overload a particular path." [RFC6438] > >> All I'm saying is >> that *any* kind of predictability of future flows is a weakness that we >> should avoid. > > I'm generally of the idea that "random is your friend" (wherever possible). > > That said, I'm also arguing that when analyzing the security properties > of something, the threat model should be clearly defined. I think it's fairly clear: the attacker reverse-engineers a load balancer and figures out how to make it send too many flows in the same direction, thereby saturating a target. > > For yet another example, draft-gont-predictable-fragment-id. My original > proposal was to simply randomize the Fragment Identification. But > concerns with collisions of Fragment IDs led to alternative approaches > (although I personally think that that doesn't mean that simple Fragment > ID randomization should be ruled out). > > >>>>> Since FlowLabels do not carry any specific semantics, I cannot see how >>>>> "forge and inject before..." would be any worse than firing those >>>>> packets once the flow has already been established. >>>> Injection of state into the endpoints may influence a large number of >>>> functions, so an attacker's ability to forge packets may allow it to >>>> skew the behavior of one of the nodes. >>> Not sure what you mean.... >> Load balancing is an example. I think you'd be courageous to assert >> that the bad guys won't find another. > > I just have not seen any example in which an algorithm such as the one > in "draft-gont-6man-flowlabel-security-02" would allow an attacker to do > something that he cannot do with randomized (as in rand()) FlowLabels. > > And I'm just saying that if the attacker is on-path, what algorithm you > use is mostly irrelevant. Unless you know all the load balancing algorithms in present and future use, I don't see how you can assert that. > > >>> How? And more importantly, why would an attacker want to forge a future >>> label that is not in use? >>> >>> Let's keep in mind that if the attacker is on-path, that of attacking >>> the flow label is probably the last DoS variant an attacker could try >>> (no amplification, etc.) >> They will try anything that works, > > Again: Is there any benefit an attacker would get from knowing what FLs > might be used in the future? > > For instance, if the FLs are not in use, it doesn't seem to make sense > for an attacker to start firing packets with such labels, as those > packet would not compete with the "real ones". And if the attacker is > on-path, then he'll play lazy, and would simply learn the labels from > the wire. > Again: I don't know, and you don't know, what use future load balancers might make of flow label values. I do know that if the sequence of flow labels is even partly predictable, the behaviour of load balancers *might* become partly predictable. > >> in the end. I think it's very cheap >> to avoid this risk - in your notation, it means >> >> Flow Label = counter + F(Source Address, Destination Address, Secret Key) >> >> is changed to >> >> Flow Label = F(Source Address, Destination Address, Secret Key, counter) >> >> That means that the regularity introduced by the counter is hidden by >> the hash function. > > This also means that the algorithm is now broken. The goal of F() is to > produce a constant value for each set (src IP, dst IP), which cannot be > easily guessable by an off-path attacker (F() introduces the > randomization). Then counter is incremented for each new label, such > that for each set (src IP, dst IP) you get monotonically-increasing flow > bales, such that the FL reuse frequency is minimized (please see the > sampl output in the I-D). But you greatly increase predictability as a result. I don't understand how that can possibly be a good thing. > If you introduce "counter" within F(), it's like changing the secret key > for every flow label, at which point the result of F() is probably not > better than than of "rand()". That depends entirely on the quality of F(); as I've already said, I hope to have some results for various algorithms and some large IPv6 packet traces quite soon, but I already know that FNV1a gives very good results. Brian From fgont@si6networks.com Sun Jan 29 20:28:33 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9280521F850F for ; Sun, 29 Jan 2012 20:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.941, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSYKPz8uetKO for ; Sun, 29 Jan 2012 20:28:33 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id CDAB621F84EC for ; Sun, 29 Jan 2012 20:28:32 -0800 (PST) Received: from [190.48.205.214] (helo=[10.42.43.100]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rriqx-00071g-PW; Mon, 30 Jan 2012 05:28:30 +0100 Message-ID: <4F261C60.1040601@si6networks.com> Date: Mon, 30 Jan 2012 01:28:16 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Fragment ID generation and Flow Label generation References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> <4F22F884.1080101@si6networks.com> <4F23219A.10101@si6networks.com> <4F23AAFC.6010404@si6networks.com> <4F25A206.1070701@gmail.com> In-Reply-To: <4F25A206.1070701@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Philip Homburg , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 04:28:33 -0000 On 01/29/2012 04:46 PM, Brian E Carpenter wrote: >> A similar approach could be implemented for the generation of >> Fragment Identification values. >> >> Thus, even if you needed to empty the Destinations Cache, you'd >> still have the benefit that the algorithm: * Makes the IDs (either >> FL or Fragment ID) difficult to guess by an off-path attacker * >> Minimize the reuse frequency of the corresponding IDs. > > I think it's a mistake to draw a strong analogy between the flow > label and the fragment ID. Well, both of the algorithms I was describing had the same goals -- hence the comment. > When the flow label is used for any form of load distribution, it > really doesn't matter if occasional flows share the same label > value, as long as this is statistially rare. It just means that the > two flows might happen to follow the same path - so what? Thus, a > completely stateless algorithm is fine and the counter brings no > benefit. I don't quite understand why you tag the hash based-algorithm as stateful, or, put another way, why you don't tag as "stateful" your algorithm as well. The second variant in draft-gont-6man-flowlabel-security requires a set of e.g. 256 (or more) system-wide counters. That's it. If you flag the algorithm as stateful just because of that, you may as well tag any algorithm that uses a PRNG as "stateful", because the PRNG usually implies internal state, too. That said, picking a random number is seen by some as "expensive" (as opposed to just increment a counter). So there you have a trade-off, too. (e.g., the hash-based approach may be cheaper CPU-wise). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Sun Jan 29 21:25:00 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65A21F84D5 for ; Sun, 29 Jan 2012 21:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, MANGLED_OFF=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-zWNt+siuf6 for ; Sun, 29 Jan 2012 21:24:59 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD621F84C8 for ; Sun, 29 Jan 2012 21:24:59 -0800 (PST) Received: from [190.48.205.214] (helo=[10.42.43.100]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rrjja-0007Kl-HP; Mon, 30 Jan 2012 06:24:55 +0100 Message-ID: <4F26299F.10806@si6networks.com> Date: Mon, 30 Jan 2012 02:24:47 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt References: <20120113130238.26417.24991.idtracker@ietfa.amsl.com> <4F1E06DF.2090307@gmail.com> <4F1E1C38.1070901@si6networks.com> <4F1E1FC3.2000206@gmail.com> <4F1E30C4.8020408@si6networks.com> <4F1F121D.40409@gmail.com> <4F1F1C64.5010008@si6networks.com> <4F1F6B79.7070008@gmail.com> <4F1FD701.9050402@si6networks.com> <4F200713.6070609@innovationslab.net> <4F200CB5.4080907@si6networks.com> <4F20614E.9000102@gmail.com> <4F2130D4.4010707@si6networks.com> <4F2614CE.1000808@gmail.com> In-Reply-To: <4F2614CE.1000808@gmail.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Brian Haberman , ipv6@ietf.org X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 05:25:00 -0000 On 01/30/2012 12:55 AM, Brian E Carpenter wrote: >>> and in particular how it interacts >>> with the flow label, then there might be a way to bias the load balancing >>> and orchestrate a DOS SYN attack on a particular server. >> >> Not sure what you mean. Are you arguing that in this case the flow-label >> would be used for *server* load-balancing? > > Yes (draft-carpenter-v6ops-label-balance) but there could be a similar > argument for ECMP or LAG, where "the worst an attacker > could do against ECMP or LAG is attempt to selectively overload a > particular path." [RFC6438] Again: If using a specific value has any semantics other than just "identifying a flow", *that* is where the vulnerability is being introduced. >>> All I'm saying is >>> that *any* kind of predictability of future flows is a weakness that we >>> should avoid. >> >> I'm generally of the idea that "random is your friend" (wherever possible). >> >> That said, I'm also arguing that when analyzing the security properties >> of something, the threat model should be clearly defined. > > I think it's fairly clear: the attacker reverse-engineers a load balancer > and figures out how to make it send too many flows in the same direction, > thereby saturating a target. Well, that's a security-unwise approach. If you're concerned about that possible attack, use some local secret such that, even if the attacker knows the algorithm and the FL, he cannot really control the load sharing at his own will. >> I just have not seen any example in which an algorithm such as the one >> in "draft-gont-6man-flowlabel-security-02" would allow an attacker to do >> something that he cannot do with randomized (as in rand()) FlowLabels. >> >> And I'm just saying that if the attacker is on-path, what algorithm you >> use is mostly irrelevant. > > Unless you know all the load balancing algorithms in present and future use, > I don't see how you can assert that. It's the intended semantics for the FL and threat model that matters, rather than the algorithm. If the attacker is on-path, he can always learn the FLs in use, and forge packets with that FL such that his packets are sent on the same link as the legitimate packets (e.g. overloading the link) -- and you cannot do anything about that (other than preventing the attacker from snooping the packets, or forging the attack packets). The other possible threat is that of an attacker being able to send his packets on any particular link, at his own will. In that case, you should assume the attacker knows your algorithm, and that he can also pick the FLs he'll use. Therefore, it is the algorithm itself that must prevent the attacker from being able to do that (e.g., employ a secret). As noted, I'm not arguing that randomizing the FL is a bad thing. I'm just arguing that the rationale for claiming that simple randomization is better than other possible approaches is flawed. >> Again: Is there any benefit an attacker would get from knowing what FLs >> might be used in the future? >> >> For instance, if the FLs are not in use, it doesn't seem to make sense >> for an attacker to start firing packets with such labels, as those >> packet would not compete with the "real ones". And if the attacker is >> on-path, then he'll play lazy, and would simply learn the labels from >> the wire. > > Again: I don't know, and you don't know, According to my analysis, there isn't. -- So if you want to declare a "winner" among algorithms (particularly when there *are* tradeoffs) based, then you should be able to answer that question. > what use future load balancers might make of flow label values. We'll we should be providing guidance on how we expect the FL to be used, shouldn't we? > I do know that if the sequence of flow > labels is even partly predictable, the behaviour of load balancers *might* > become partly predictable. That is true only if the load balancer implementation is flawed. >>> in the end. I think it's very cheap >>> to avoid this risk - in your notation, it means >>> >>> Flow Label = counter + F(Source Address, Destination Address, Secret Key) >>> >>> is changed to >>> >>> Flow Label = F(Source Address, Destination Address, Secret Key, counter) >>> >>> That means that the regularity introduced by the counter is hidden by >>> the hash function. >> >> This also means that the algorithm is now broken. The goal of F() is to >> produce a constant value for each set (src IP, dst IP), which cannot be >> easily guessable by an off-path attacker (F() introduces the >> randomization). Then counter is incremented for each new label, such >> that for each set (src IP, dst IP) you get monotonically-increasing flow >> bales, such that the FL reuse frequency is minimized (please see the >> sampl output in the I-D). > > But you greatly increase predictability as a result. I don't understand > how that can possibly be a good thing. I don't understand the basis on which you flag things as "good" or "bad". If you can come up with a scenario in which *on-path* predictability makes possible attacks that simple randomization doesn't, then I would buy your argument. But so far it looks more like religion than anything else. >> If you introduce "counter" within F(), it's like changing the secret key >> for every flow label, at which point the result of F() is probably not >> better than than of "rand()". > > That depends entirely on the quality of F(); as I've already said, Not sure what you mean. If F() has the properties described in draft-gont-6man-flowlabel-security-02, the adding the counter as you described breaks the algorithm. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tore.anderson@redpill-linpro.com Mon Jan 30 01:43:57 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7A021F84F7 for ; Mon, 30 Jan 2012 01:43:57 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTeeojcfpjKz for ; Mon, 30 Jan 2012 01:43:57 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC0721F84F2 for ; Mon, 30 Jan 2012 01:43:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id F21EF112803A; Mon, 30 Jan 2012 10:43:54 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrQEs1qLQg7g; Mon, 30 Jan 2012 10:43:54 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 5D48C112800A; Mon, 30 Jan 2012 10:43:54 +0100 (CET) Message-ID: <4F26665A.5030303@redpill-linpro.com> Date: Mon, 30 Jan 2012 10:43:54 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Fernando Gont Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> In-Reply-To: <4F22922A.1090603@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Philip Homburg , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 09:43:57 -0000 * Florian Weimer >> And I see no functional difference between the gateway and the host >> generating the fragment ID, except that the latter approach seems to >> require network-wide software updates currently. A stateless translator does not keep track of the PMTU for the IPv4 destinations. That means that for it to work, it would have to clear the Don't Fragment flag and generate a Fragment ID for every single packet it translates to IPv4 that ends up smaller than 1260 bytes. I don't believe this is desirable. Also, RFC 2460 would have to be amended in order to allow hosts to outright ignore ICMPv6 PTB w/MTU<1280, and the IPv6 host stacks would also have to be updated accordingly. It seems to me, therefore, that the approach of having the translator generate the Fragment ID is the one that requires the most network-wide software updates. * Fernando Gont > Namely, are you saying that Linux won't react to an ICMPv6 PTB<1280 by > inserting a Fragment Header in subsequent packets, or what? (last time I > checked, I think this was the case) I can confirm that Linux will react to an ICMPv6 PTB<1280 by including a Fragment header. There are a couple of bugs in its implementation, but I expect these to be fixed shortly (patches are already available). https://bugzilla.kernel.org/show_bug.cgi?id=42572 https://bugzilla.kernel.org/show_bug.cgi?id=42595 -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From fweimer@bfk.de Mon Jan 30 02:06:46 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A1321F867C for ; Mon, 30 Jan 2012 02:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcklYcNE1Kmp for ; Mon, 30 Jan 2012 02:06:46 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id D3E5421F867A for ; Mon, 30 Jan 2012 02:06:45 -0800 (PST) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1Rro8I-0006RP-1g; Mon, 30 Jan 2012 10:06:42 +0000 Received: by bfk.de with local id 1Rro8H-0004ZX-TX; Mon, 30 Jan 2012 10:06:41 +0000 From: Florian Weimer To: Tore Anderson Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <4F26665A.5030303@redpill-linpro.com> Date: Mon, 30 Jan 2012 10:06:41 +0000 In-Reply-To: <4F26665A.5030303@redpill-linpro.com> (Tore Anderson's message of "Mon, 30 Jan 2012 10:43:54 +0100") Message-ID: <824nvdld1q.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Philip Homburg , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 10:06:46 -0000 * Tore Anderson: > * Florian Weimer > >>> And I see no functional difference between the gateway and the host >>> generating the fragment ID, except that the latter approach seems to >>> require network-wide software updates currently. > > A stateless translator does not keep track of the PMTU for the IPv4 > destinations. That means that for it to work, it would have to clear the > Don't Fragment flag and generate a Fragment ID for every single packet > it translates to IPv4 that ends up smaller than 1260 bytes. I don't > believe this is desirable. Why? You should generate the fragment ID anyway because some networks will fragment DF=3D1 packets. > Also, RFC 2460 would have to be amended in order to allow hosts to > outright ignore ICMPv6 PTB w/MTU<1280, and the IPv6 host stacks would > also have to be updated accordingly. It seems to me, therefore, that the > approach of having the translator generate the Fragment ID is the one > that requires the most network-wide software updates. Affected translators are in the minority. Their vendors will implement the change (i.e., fragment IPv6 packets without fragment headers) because that's what's required to get them working with the currrent network. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From tore.anderson@redpill-linpro.com Mon Jan 30 03:18:24 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FA521F8618 for ; Mon, 30 Jan 2012 03:18:24 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSOCIEpE34Ve for ; Mon, 30 Jan 2012 03:18:23 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 560AB21F8615 for ; Mon, 30 Jan 2012 03:18:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id E50D9112803A; Mon, 30 Jan 2012 12:18:21 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtp1KJWTHClV; Mon, 30 Jan 2012 12:18:21 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id 6494D112800A; Mon, 30 Jan 2012 12:18:21 +0100 (CET) Message-ID: <4F267C7D.1090800@redpill-linpro.com> Date: Mon, 30 Jan 2012 12:18:21 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Florian Weimer Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <4F26665A.5030303@redpill-linpro.com> <824nvdld1q.fsf@mid.bfk.de> In-Reply-To: <824nvdld1q.fsf@mid.bfk.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Philip Homburg , "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:18:24 -0000 * Florian Weimer > * Tore Anderson: > >> * Florian Weimer >> >>>> And I see no functional difference between the gateway and the host >>>> generating the fragment ID, except that the latter approach seems to >>>> require network-wide software updates currently. >> >> A stateless translator does not keep track of the PMTU for the IPv4 >> destinations. That means that for it to work, it would have to clear the >> Don't Fragment flag and generate a Fragment ID for every single packet >> it translates to IPv4 that ends up smaller than 1260 bytes. I don't >> believe this is desirable. > > Why? Because the network ends up second-guessing the host. RFC 2460 allows IPv6 nodes to act on ICMPv6 PTBs w/MTU < 1280 by simply lowering the Path MTU for the destination to the indicated value. In other words, an IPv6 node can perform Path MTU Discovery for translated IPv4 destinations behind IPv4 links that have smaller MTU than 1260. I actually prefer this approach to the "lower MTU to exactly 1280 and include Fragment headers" alternative. However, if the translator is clearing the DF flag when translating o IPv4, the IPv6 host cannot perform PMTUD anymore. > You should generate the fragment ID anyway because some networks will > fragment DF=1 packets. I'm okay with generating the Fragment ID, I think. RFC 6145 section 5.1 says a translator MAY do so. What I'm not okay with is clearing the DF flag. >> Also, RFC 2460 would have to be amended in order to allow hosts to >> outright ignore ICMPv6 PTB w/MTU<1280, and the IPv6 host stacks would >> also have to be updated accordingly. It seems to me, therefore, that the >> approach of having the translator generate the Fragment ID is the one >> that requires the most network-wide software updates. > > Affected translators are in the minority. Their vendors will implement > the change (i.e., fragment IPv6 packets without fragment headers) > because that's what's required to get them working with the currrent > network. I'm running a stateless translator (a Cisco ASR1K) in front of our corporate homepage as we speak. It handles «atomic fragments» originated by the IPv6-only web server perfectly in the way RFC 6145 mandates. Absolutely *nothing* is required to change in order "to get it working with the current network". In any case, changing the translators won't stop RFC 2460-compliant nodes from generating these atomic fragments. If you want to make that happen, you need to change the host stacks so that they discard ICMPv6 PTB w/MTU<1280 (or, alternatively, implement them by lowering the PMTU to whatever MTU value indicated in the PTB, even if it's <1280). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From tore.anderson@redpill-linpro.com Mon Jan 30 03:25:39 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF87021F86AD for ; Mon, 30 Jan 2012 03:25:39 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPbRitrPjkUZ for ; Mon, 30 Jan 2012 03:25:39 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A84421F869D for ; Mon, 30 Jan 2012 03:25:39 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 757D9112803A; Mon, 30 Jan 2012 12:25:38 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdngwoCOQt9I; Mon, 30 Jan 2012 12:25:37 +0100 (CET) Received: from echo.linpro.no (unknown [IPv6:2a02:c0:1002:102:21d:60ff:fe48:f59e]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id C0CC7112800A; Mon, 30 Jan 2012 12:25:37 +0100 (CET) Message-ID: <4F267E31.7020505@redpill-linpro.com> Date: Mon, 30 Jan 2012 12:25:37 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Brian Haberman Subject: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments References: <4F148730.6030308@innovationslab.net> In-Reply-To: <4F148730.6030308@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 11:25:39 -0000 * Brian Haberman > This is a consensus call on adopting: > > Title : Processing of IPv6 "atomic" fragments > Author(s) : Fernando Gont > Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt > Pages : 12 > Date : 2011-12-15 > > as a 6MAN working group document. Support. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com From timothyhartrick@gmail.com Mon Jan 30 08:26:54 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1504711E8080 for ; Mon, 30 Jan 2012 08:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DbBP5Tj0paB for ; Mon, 30 Jan 2012 08:26:53 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64BC011E807F for ; Mon, 30 Jan 2012 08:26:53 -0800 (PST) Received: by pbdu7 with SMTP id u7so4083276pbd.31 for ; Mon, 30 Jan 2012 08:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qxDDIh77OZ+bt1NnB0Jpl9625W2aNFv7rnTUzGa9pqk=; b=n6Fup5QqKjNncm6fB6F/HHiH+nxFVbSwoqHXSyUKdB3rKAHVinJbfMDNjlK+fheFNK 40M96XQcxSX5BEwJjTKgoQoChzbgpv6ro5pAJP3ZGsBVRRCOXvfY7l+h1WlkDVxqOjYM xHGqZ3R4See5o4G8B2mY/1NN/klbVRF1knz1Q= MIME-Version: 1.0 Received: by 10.68.240.164 with SMTP id wb4mr42686824pbc.57.1327940813258; Mon, 30 Jan 2012 08:26:53 -0800 (PST) Received: by 10.68.50.137 with HTTP; Mon, 30 Jan 2012 08:26:53 -0800 (PST) In-Reply-To: <4F148730.6030308@innovationslab.net> References: <4F148730.6030308@innovationslab.net> Date: Mon, 30 Jan 2012 08:26:53 -0800 Message-ID: Subject: Re: Consensus call on adopting: draft-gont-6man-ipv6-atomic-fragments From: Timothy Hartrick To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b15aadd74ffda04b7c150d5 X-Mailman-Approved-At: Mon, 30 Jan 2012 08:29:35 -0800 Cc: 6man Chairs <6man-chairs@tools.ietf.org>, IPv6 WG Mailing List X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:26:54 -0000 --047d7b15aadd74ffda04b7c150d5 Content-Type: text/plain; charset=ISO-8859-1 Brian, I support this work. Tim Hartrick On Mon, Jan 16, 2012 at 12:23 PM, Brian Haberman wrote: > All, > This is a consensus call on adopting: > > Title : Processing of IPv6 "atomic" fragments > Author(s) : Fernando Gont > Filename : draft-gont-6man-ipv6-atomic-fragments-00.txt > Pages : 12 > Date : 2011-12-15 > > as a 6MAN working group document. Please state your opinion, positive > or negative, on the mailing list or to the chairs. This consensus call > will end on January 31, 2012. > > Regards, > Brian & Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --047d7b15aadd74ffda04b7c150d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brian,

I support this work.


Tim Hartrick


<= br>
On Mon, Jan 16, 2012 at 12:23 PM, Brian Haber= man <brian= @innovationslab.net> wrote:
All,
=A0 =A0 This is a consensus call on adopting:

=A0 =A0 Title =A0 =A0 : Processing of IPv6 "atomic" fragments =A0 =A0 Author(s) : Fernando Gont
=A0 =A0 Filename =A0: draft-gont-6man-ipv6-atomic-fragments-00.txt
=A0 =A0 Pages =A0 =A0 : 12
=A0 =A0 Date =A0 =A0 =A0: 2011-12-15

as a 6MAN working group document. =A0Please state your opinion, positive or negative, on the mailing list or to the chairs. =A0This consensus call will end on January 31, 2012.

Regards,
Brian & Bob
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--047d7b15aadd74ffda04b7c150d5-- From pch-b29AA871B@u-1.phicoh.com Mon Jan 30 13:20:59 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5691F0C4F for ; Mon, 30 Jan 2012 13:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.455 X-Spam-Level: X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjkd4mrOD9xg for ; Mon, 30 Jan 2012 13:20:57 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 56CF71F0C4E for ; Mon, 30 Jan 2012 13:20:57 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rryej-0001iuC; Mon, 30 Jan 2012 22:20:53 +0100 Message-Id: To: Tore Anderson Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <4F26665A.5030303@redpill-linpro.com> <824nvdld1q.fsf@mid.bfk.de> <4F267C7D.1090800@redpill-linpro.com> In-reply-to: Your message of "Mon, 30 Jan 2012 12:18:21 +0100 ." <4F267C7D.1090800@redpill-linpro.com> Date: Mon, 30 Jan 2012 22:20:52 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:20:59 -0000 In your letter dated Mon, 30 Jan 2012 12:18:21 +0100 you wrote: >Because the network ends up second-guessing the host. RFC 2460 allows >IPv6 nodes to act on ICMPv6 PTBs w/MTU < 1280 by simply lowering the >Path MTU for the destination to the indicated value. In other words, an >IPv6 node can perform Path MTU Discovery for translated IPv4 >destinations behind IPv4 links that have smaller MTU than 1260. >From RFC-2460: "In response to an IPv6 packet that is sent to an IPv4 destination "(i.e., a packet that undergoes translation from IPv6 to IPv4), the "originating IPv6 node may receive an ICMP Packet Too Big message "reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node "is not required to reduce the size of subsequent packets to less than "1280, but must include a Fragment header in those packets so that the "IPv6-to-IPv4 translating router can obtain a suitable Identification "value to use in resulting IPv4 fragments. Note that this means the "payload may have to be reduced to 1232 octets (1280 minus 40 for the "IPv6 header and 8 for the Fragment header), and smaller still if "additional extension headers are used. Yes, it is allowed. But what do you do with hosts that do not do this? And what do you do with the resulting denial of service attack if you allow anybody to lower your mtu to very small values? You want to import all the bad things of IPv4? From pch-b29AA871B@u-1.phicoh.com Mon Jan 30 13:28:08 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61DB21F858E for ; Mon, 30 Jan 2012 13:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.471 X-Spam-Level: X-Spam-Status: No, score=-8.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVjcBDKW8gst for ; Mon, 30 Jan 2012 13:28:08 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2235C21F858B for ; Mon, 30 Jan 2012 13:28:08 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rrylh-0001jOC; Mon, 30 Jan 2012 22:28:05 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> <4F24879E.8000002@si6networks.com> In-reply-to: Your message of "Sat, 28 Jan 2012 20:41:18 -0300 ." <4F24879E.8000002@si6networks.com> Date: Mon, 30 Jan 2012 22:28:04 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:28:09 -0000 In your letter dated Sat, 28 Jan 2012 20:41:18 -0300 you wrote: >That said, nobody is *introducing* atomic fragments.They should have >been supported for more than 15 years, and there is other stuff >(mentioned by Dan Wing at others) that would break without this. Currently, atomic fragments are rare. You can easily see that many DNS servers are not doing any kind of PMTUD. They just fragment at 1280. What RFC-2460 effectively says is that if you are not doing PMTUD, then each and every outgoing packet has to be an atomic fragment. I'm not seeing that on todays IPv6 network. So that would be completely new. From pch-b29AA871B@u-1.phicoh.com Mon Jan 30 13:50:02 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768A221F850C for ; Mon, 30 Jan 2012 13:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.484 X-Spam-Level: X-Spam-Status: No, score=-8.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGqyeSbRLUdi for ; Mon, 30 Jan 2012 13:50:01 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3A03C21F8489 for ; Mon, 30 Jan 2012 13:50:01 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1Rrz6t-0001isC; Mon, 30 Jan 2012 22:49:59 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragment ID generation and Flow Label generation (was: Re: Fragmentation-related security issues) From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <4F22CE8C.2030107@si6networks.com> <4F22F884.1080101@si6networks.com> <4F23219A.10101@si6networks.com> In-reply-to: Your message of "Fri, 27 Jan 2012 19:13:46 -0300 ." <4F23219A.10101@si6networks.com> Date: Mon, 30 Jan 2012 22:49:59 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:50:02 -0000 In your letter dated Fri, 27 Jan 2012 19:13:46 -0300 you wrote: >> For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on >> pmtud gives a bad user experience. > >Since IPv4 MTUs can be as low as 296, and since I doubt you clamp the >MSS to such a low value, you still rely on PMTUD. (Hopefully you system >imlements PMTUD + PLPMTUD for blackhole detection). The whole point of MTU clamping is you set it to whatever is the lowest on paths between you host and the first IX, transit or what not, where the MTU is at least 1500. So if you have 296 locally somewhere, then yes, you would have to set the mss that low. The reason is that too many sending systems are broken. If you don't set the mss, then may up with failing tcp connection in too many cases. >> PMTU blackhole detection is surprisingly uncommon. > >It is implemented in OpenBSD, I recall it bein implemented in Windows... >so I don't think it is uncommon. Maybe there is just too much Linux around then :-) Does implemented in Windows also mean that it is enabled in just about all cases? Otherwise, we're back to square one. >> With random IDs, every packet that arrives has a 1/65536 chance of colliding >> with a packet that is awaiting reassembly. Total chance depends on the >> reassembly timeout and the packets rate. > >And most importantly, the loss rate. Add a bad combination of reassembly >timeout + loss rate + data rate, and you're toast. > >See e.g. There is an interesting calculation there. Effectively, above 20 Mbit/s you are toast anyhow. And let me repeat, this is only an issue for IPv4 links with an mtu smaller than 1280 and where there is also a one-to-one correspondance between IPv6 and IPv4 address in the stateless-NAT box. This gets into the exceedingly rare territory. >> I don't particularly care about the translators. > >There are other sources of this traffic. It has been reported on the >list that this traffic has been found on the wild. I tried to find that message but I can't. Do you have a message ID? From fgont@si6networks.com Mon Jan 30 15:42:43 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700B611E80E9 for ; Mon, 30 Jan 2012 15:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.675 X-Spam-Level: X-Spam-Status: No, score=-2.675 tagged_above=-999 required=5 tests=[AWL=1.924, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7poYOZDT5Tve for ; Mon, 30 Jan 2012 15:42:42 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 346C811E80DC for ; Mon, 30 Jan 2012 15:42:42 -0800 (PST) Received: from [190.48.244.14] (helo=[10.42.43.100]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Rs0rs-0007aA-4D; Tue, 31 Jan 2012 00:42:36 +0100 Message-ID: <4F272AE3.5080208@si6networks.com> Date: Mon, 30 Jan 2012 20:42:27 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> <4F24879E.8000002@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:42:43 -0000 On 01/30/2012 06:28 PM, Philip Homburg wrote: > In your letter dated Sat, 28 Jan 2012 20:41:18 -0300 you wrote: >> That said, nobody is *introducing* atomic fragments.They should have >> been supported for more than 15 years, and there is other stuff >> (mentioned by Dan Wing at others) that would break without this. > > Currently, atomic fragments are rare. > [...] > > I'm not seeing that on todays IPv6 network. So that would be completely > new. See this: https://bugzilla.kernel.org/show_bug.cgi?id=42572 https://bugzilla.kernel.org/show_bug.cgi?id=42595 And this: http://article.gmane.org/gmane.ietf.ipv6/22728 And there are others... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From tore.anderson@redpill-linpro.com Mon Jan 30 17:03:18 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1529E11E80F6 for ; Mon, 30 Jan 2012 17:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRi4cDx58DMD for ; Mon, 30 Jan 2012 17:03:17 -0800 (PST) Received: from zimbra.redpill-linpro.com (zimbra.redpill-linpro.com [IPv6:2a02:c0:200:c000::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF34D11E80EC for ; Mon, 30 Jan 2012 17:03:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.redpill-linpro.com (Postfix) with ESMTP id 7C930103000A; Tue, 31 Jan 2012 02:03:14 +0100 (CET) X-Virus-Scanned: amavisd-new at claudius.linpro.no Received: from zimbra.redpill-linpro.com ([127.0.0.1]) by localhost (zimbra.redpill-linpro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRU2-LdUgJyX; Tue, 31 Jan 2012 02:03:13 +0100 (CET) Received: from envy.fud.no (unknown [IPv6:2001:840:3035:20:21c:bfff:fe02:f2a5]) by zimbra.redpill-linpro.com (Postfix) with ESMTPSA id AB8341030006; Tue, 31 Jan 2012 02:03:13 +0100 (CET) Message-ID: <4F273DD1.3020007@redpill-linpro.com> Date: Tue, 31 Jan 2012 02:03:13 +0100 From: Tore Anderson Organization: Redpill Linpro AS User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <4F26665A.5030303@redpill-linpro.com> <824nvdld1q.fsf@mid.bfk.de> <4F267C7D.1090800@redpill-linpro.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 01:03:18 -0000 * Philip Homburg > In your letter dated Mon, 30 Jan 2012 12:18:21 +0100 you wrote: >> Because the network ends up second-guessing the host. RFC 2460 allows >> IPv6 nodes to act on ICMPv6 PTBs w/MTU < 1280 by simply lowering the >> Path MTU for the destination to the indicated value. In other words, an >> IPv6 node can perform Path MTU Discovery for translated IPv4 >> destinations behind IPv4 links that have smaller MTU than 1260. > > From RFC-2460: > "In response to an IPv6 packet that is sent to an IPv4 destination > "(i.e., a packet that undergoes translation from IPv6 to IPv4), the > "originating IPv6 node may receive an ICMP Packet Too Big message > "reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node > "is not required to reduce the size of subsequent packets to less than > "1280, but must include a Fragment header in those packets so that the > "IPv6-to-IPv4 translating router can obtain a suitable Identification > "value to use in resulting IPv4 fragments. Note that this means the > "payload may have to be reduced to 1232 octets (1280 minus 40 for the > "IPv6 header and 8 for the Fragment header), and smaller still if > "additional extension headers are used. > > Yes, it is allowed. But what do you do with hosts that do not do this? An IPv6 node conforming to the language above must either A) allow PMTUD to work even if the PMTU is <1280, or B) create atomic fragments in order to indicate that it wants the DF flag cleared and IPv4 routers to perform fragmentation. Either approach is valid, and work well today. > And what do you do with the resulting denial of service attack if you allow > anybody to lower your mtu to very small values? Nothing in particular. I haven't had any problems with this in neither IPv4 nor in IPv6, so I can't say I'm terribly concerned about it. In any case, the atomic fragment approach is available for anyone who is concerned about allowing the IPv6 PMTU to drop to IPv4 levels. > You want to import all the bad things of IPv4? Appeal to ridicule / straw man -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From pch-b29AA871B@u-1.phicoh.com Tue Jan 31 03:12:35 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F72321F8569 for ; Tue, 31 Jan 2012 03:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.494 X-Spam-Level: X-Spam-Status: No, score=-8.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7dCrV9Rn1vl for ; Tue, 31 Jan 2012 03:12:34 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id A970221F8552 for ; Tue, 31 Jan 2012 03:12:33 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #76) id m1RsBdU-0001jIC; Tue, 31 Jan 2012 12:12:28 +0100 Message-Id: To: Fernando Gont Subject: Re: Fragmentation-related security issues From: Philip Homburg Sender: pch-b29AA871B@u-1.phicoh.com References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> <4F24879E.8000002@si6networks.com> <4F272AE3.5080208@si6networks.com> In-reply-to: Your message of "Mon, 30 Jan 2012 20:42:27 -0300 ." <4F272AE3.5080208@si6networks.com> Date: Tue, 31 Jan 2012 12:12:27 +0100 Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:12:35 -0000 In your letter dated Mon, 30 Jan 2012 20:42:27 -0300 you wrote: >On 01/30/2012 06:28 PM, Philip Homburg wrote: >> In your letter dated Sat, 28 Jan 2012 20:41:18 -0300 you wrote: >>> That said, nobody is *introducing* atomic fragments.They should have >>> been supported for more than 15 years, and there is other stuff >>> (mentioned by Dan Wing at others) that would break without this. >> >> Currently, atomic fragments are rare. >> >[...] >> >> I'm not seeing that on todays IPv6 network. So that would be completely >> new. > >See this: Let's say that my thesis is that all atomic fragments are directly or indirectly caused by the support for stateless NAT in RFC-2460. Then what do we get: >https://bugzilla.kernel.org/show_bug.cgi?id=42572 "An IPv4 client behind a link with a MTU of 1259 downloading a file from an IPv6 server" So yes. >https://bugzilla.kernel.org/show_bug.cgi?id=42595 "If the allfrag feature has been set on a host route (due to an ICMPv6 Packet Too Big received indicating a MTU of less than 1280)" Again yes. >And this: > >http://article.gmane.org/gmane.ietf.ipv6/22728 "Such traffic absolutely occurs in the wild. I have three reasonably busy name servers where this is logged as an error from the ipfw code, e.g." Inconclusive. We don't know why that traffic is there. So, just remove that requirement from RFC-2460, and the problem is gone. From fernando.gont.netbook.win@gmail.com Tue Jan 31 10:59:01 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BC211E8124 for ; Tue, 31 Jan 2012 10:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3aZeEC9Z67J for ; Tue, 31 Jan 2012 10:59:01 -0800 (PST) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id F2CB311E808E for ; Tue, 31 Jan 2012 10:59:00 -0800 (PST) Received: by yhfs35 with SMTP id s35so253514yhf.27 for ; Tue, 31 Jan 2012 10:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=q9yROB3pZH/iRzuAVhGnkvvNZPTgUkPYkGF2rPzcAT8=; b=iv5j3l8CLBDwA3H/BFjMdxAbUWu7SLOd+LI+vRIHLiSJElVYgDgXPPTy+QXcz5mBV1 qYD9TGNqILSr1WhPkVuNtsBcrMSJ4GHjTmpNtvi5iFHWKLPC0JzG9B6sgg5lqEXGhpa/ p35vB4TS8RPGAwlv6/3wpFRpZw5ksPni6Z4lE= Received: by 10.236.73.129 with SMTP id v1mr37118195yhd.129.1328036340638; Tue, 31 Jan 2012 10:59:00 -0800 (PST) Received: from [10.42.43.100] ([190.48.252.10]) by mx.google.com with ESMTPS id b7sm40641676yhm.0.2012.01.31.10.58.57 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 10:58:58 -0800 (PST) Sender: Fernando Gont Message-ID: <4F2839EF.2090100@gont.com.ar> Date: Tue, 31 Jan 2012 15:58:55 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Philip Homburg Subject: Re: Fragmentation-related security issues References: <4EEA0342.2040608@si6networks.com> <82fwgfk1ev.fsf@mid.bfk.de> <4EF0FFDF.6010703@gont.com.ar> <82d3bfbm5l.fsf@mid.bfk.de> <82aa59sao5.fsf@mid.bfk.de> <82vcnxqsw5.fsf@mid.bfk.de> <4F22922A.1090603@si6networks.com> <82r4ylqr4q.fsf@mid.bfk.de> <4F22CBCA.5040106@si6networks.com> <824nvfq4wg.fsf@mid.bfk.de> <4F24879E.8000002@si6networks.com> <4F272AE3.5080208@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:59:01 -0000 On 01/31/2012 08:12 AM, Philip Homburg wrote: > "Such traffic absolutely occurs in the wild. I have three reasonably > busy name servers where this is logged as an error from the ipfw code, > e.g." > > Inconclusive. We don't know why that traffic is there. > > So, just remove that requirement from RFC-2460, and the problem is gone. If you're meaning to remove support for some feature from the standard on the basis that it is not used, then the *you* should prove that is not being used. So far, you're arguments have been based on guesswork. People have reported that this feature is used, and have even provided packets traces showing that. I personally believe it is very dangerous to think about removing something without bothering to consider what might break, and without bothering whether there's stuff (such as translators) that depend on that feature. Fix the bug, and be done with it. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Tue Jan 31 17:51:06 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F037C11E809B for ; Tue, 31 Jan 2012 17:51:06 -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=[AWL=0.850, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKlxzQLwP8PF for ; Tue, 31 Jan 2012 17:51:06 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20011E808E for ; Tue, 31 Jan 2012 17:51:05 -0800 (PST) Received: from [190.48.255.77] (helo=[10.42.43.100]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1RsPLj-0002w5-90; Wed, 01 Feb 2012 02:51:03 +0100 Message-ID: <4F289A80.201@si6networks.com> Date: Tue, 31 Jan 2012 22:50:56 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: "ipv6@ietf.org" Subject: A small survey of support of IPv6 atomic fragments X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 01:51:07 -0000 Folks, Since there has been a bit of guesswork regarding what systems support (or do not support) IPv6 atomic fragments, I've played a bit with a few operating systems, and here are the results regarding the support of accepting incoming atomic fragments. The column entitled "Improved Processing" indicates whether the corresponding operating system already implements the improved processing of atomic fragments described in draft-gont-6man-ipv6-atomic-fragments. OS | Atomic fragments | Improved Processing -------------------+------------------+------------------------------ FreeBSD 8.2 | No | No FreeBSD 9.0 | Yes | No Linux 3.0.0-15 | Yes | Yes NetBSD 5.1 | No | No OpenBSD-current | Yes | Yes Solaris | Yes | Yes Win 7 Home Premium | Yes | No --------------------------------------------------------------------- >From this table, it should be clear that most current operating systems support them. If deemed as useful/appropriate, I could include this survey in an appendix of the next revision of draft-gont-6man-ipv6-atomic-fragments. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fernando.gont.netbook.win@gmail.com Tue Jan 31 21:23:04 2012 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2414E21F8498 for ; Tue, 31 Jan 2012 21:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNK40qjIc7Lz for ; Tue, 31 Jan 2012 21:23:02 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BADE121F8497 for ; Tue, 31 Jan 2012 21:22:54 -0800 (PST) Received: by yenm3 with SMTP id m3so436083yen.31 for ; Tue, 31 Jan 2012 21:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=nwzAp+BiVeby5u6HGHXAiM4NPKMUA+n+yzwb7NtbaaM=; b=SDQ/0s5wPHEv0vOwnpHhseQkGqbokWw3s/L58egMJ91XiH/o6BWVcnGh0Y/sSBsC5f AyVkt0K1kHDuGzcUE+RIxGgfbjRQm2QsF502bE7JJWr8nmbVzZ+6jN1iwspgP4ATdw6/ xLOROtebdFOmUDqDd2ckwBLLRLujrmTXtcQG8= Received: by 10.236.182.2 with SMTP id n2mr91462yhm.11.1328073774386; Tue, 31 Jan 2012 21:22:54 -0800 (PST) Received: from [10.42.43.100] ([190.48.255.77]) by mx.google.com with ESMTPS id i6sm61420407and.3.2012.01.31.21.22.50 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 21:22:53 -0800 (PST) Sender: Fernando Gont Message-ID: <4F28CC25.2090706@gont.com.ar> Date: Wed, 01 Feb 2012 02:22:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Fernando Gont Subject: Re: A small survey of support of IPv6 atomic fragments References: <4F289A80.201@si6networks.com> In-Reply-To: <4F289A80.201@si6networks.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 05:23:05 -0000 On 01/31/2012 10:50 PM, Fernando Gont wrote: > OS | Atomic fragments | Improved Processing > -------------------+------------------+------------------------------ > FreeBSD 8.2 | No | No > FreeBSD 9.0 | Yes | No > Linux 3.0.0-15 | Yes | Yes > NetBSD 5.1 | No | No > OpenBSD-current | Yes | Yes > Solaris | Yes | Yes > Win 7 Home Premium | Yes | No > --------------------------------------------------------------------- Minor errata: FreeBSD 8.2 does support atomic fragments (but not draft-gont-6man-ipv6-atomic-fragments). It was *FreeBSD 8.0* the system discarding the atomic fragments. Therefore, the corrected table is: OS | Atomic fragments | Improved Processing -------------------+------------------+------------------------------ FreeBSD 8.0 | No | No FreeBSD 8.2 | Yes | No FreeBSD 9.0 | Yes | No Linux 3.0.0-15 | Yes | Yes NetBSD 5.1 | No | No OpenBSD-current | Yes | Yes Solaris 11 | Yes | Yes Win 7 Home Premium | Yes | No --------------------------------------------------------------------- Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1