Re: [v6ops] A good example of why we need to careful about ULAs

Owen DeLong <owen@delong.com> Sat, 01 June 2013 06:08 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026F621F89D5 for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 23:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.204
X-Spam-Level:
X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 YZDjmGRGIQx8 for <v6ops@ietfa.amsl.com>; Fri, 31 May 2013 23:08:02 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE9121F8749 for <v6ops@ietf.org>; Fri, 31 May 2013 23:08:01 -0700 (PDT)
Received: from [IPv6:2600:100c:b210:87e6:1983:16db:e387:be5f] ([IPv6:2600:100c:b210:87e6:1983:16db:e387:be5f]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.1) with ESMTP id r5165fck012577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 31 May 2013 23:05:44 -0700
X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com r5165fck012577
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1370066746; bh=6h79qxyzCphUhatqOXMDIfybpxU=; h=References:Mime-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Message-Id:Cc:From:Subject:Date:To; b=uDeElYcZDQF2eI6FbYndSWdG/ZpoTfupKoGtJ4brT7rA2p5l2ZpZSVG63YC1pnqAp zrIi89fuYsUFzsQ2TC9DFwiY6AD1UFJ/MfRrAf9OS6HVduW7AErSCld1PpNlIqCcYd 4fNe0/sqCiMmr+VMO3CaOVfdFrR8KNKAPVbyeHpg=
References: <CAKD1Yr29kf1Me=6JR66Gq0dFYgQx2wq=pjW8WZyHByPA0POsMQ@mail.gmail.com> <1369901467.70362.YahooMailNeo@web142506.mail.bf1.yahoo.com> <51A7C86B.3020808@gmail.com> <BCEC2341-CF91-4184-B14A-FE0BE683F89F@delong.com> <8D23D4052ABE7A4490E77B1A012B6307751BFE04@mbx-01.win.nominum.com> <4CB10EDC-1E2B-4423-AD77-7B6062F80579@delong.com> <51A97375.1090402@gmail.com> <51A97918.9070404@massar.ch> <90D50EC6-D510-4A3B-B33A-32135462A233@delong.com> <51A97D9D.5010003@massar.ch>
Mime-Version: 1.0 (1.0)
In-Reply-To: <51A97D9D.5010003@massar.ch>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <BCB87E02-000C-47C2-BB30-2FF2D23359DB@delong.com>
X-Mailer: iPhone Mail (10B350)
From: Owen DeLong <owen@delong.com>
Date: Sat, 01 Jun 2013 01:05:39 -0500
To: Jeroen Massar <jeroen@massar.ch>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [IPv6:2620:0:930::200:2]); Fri, 31 May 2013 23:05:46 -0700 (PDT)
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>, "draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org" <draft-ietf-v6ops-ula-usage-recommendations@tools.ietf.org>
Subject: Re: [v6ops] A good example of why we need to careful about ULAs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Jun 2013 06:08:03 -0000

My point is that link local packets shouldn't even get far enough for BCP38 to matter. Every router is required to not forward then no matter what. If the packet gets far enough into the forwarding process for your BCP38 filters to matter, then you need a software update for the router. 

Owen

On May 31, 2013, at 23:50, Jeroen Massar <jeroen@massar.ch> wrote:

> On 2013-05-31 21:33, Owen DeLong wrote:
>> 
>> On May 31, 2013, at 9:31 PM, Jeroen Massar <jeroen@massar.ch> wrote:
>> 
>>> On 2013-05-31 21:07, Brian E Carpenter wrote: [..]
>>>> Agreed. But when it does get through, it does no particular harm
>>>> (you just see a bizarre hop in the traceroute). If it got through
>>>> in a SYN/ACK exchange, it would probably distress a user.
>>> 
>>> If such a packet gets through it means BCP38 is not applied as
>>> things are not properly filtered.
>>> 
>> 
>> This has nothing to do with BCP38.
> 
> I would say it has everything to do with it actually ;)
> 
> Especially as it covers checking ALL traffic being forwarded and doing a
> simple source check on them.
> 
>> Any router which forwards a packet containing a link local address in
>> the header is broken regardless of any BCP38 configuration.
> 
> And BCP38 (Section 3, please read it, it is really informative ;) is
> inclusive of those requirements. Of course do also take into account
> BCP84 which details things a lot more.
> 
> Note that you have a fe80::/10 on every single interface, thus receiving
> such packets from another box and trying to forward it to another
> interface is just not right as it would fail uRPF do it being present on
> multiple interfaces.
> 
> Greets,
> Jeroen