Re: What to improve? BCP-38/SAC-004 anyone?

Jared Mauch <jared@puck.nether.net> Thu, 31 December 2015 19:42 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DEA1A8A85 for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 11:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.512
X-Spam-Level:
X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t_iTMETkGp_V for <ietf@ietfa.amsl.com>; Thu, 31 Dec 2015 11:42:06 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D01A8A84 for <ietf@ietf.org>; Thu, 31 Dec 2015 11:42:04 -0800 (PST)
Received: from [IPv6:2601:401:3:6a00:d541:7674:527b:16ca] (unknown [IPv6:2601:401:3:6a00:d541:7674:527b:16ca]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id C5E4B5405CB; Thu, 31 Dec 2015 14:42:02 -0500 (EST)
Subject: Re: What to improve? BCP-38/SAC-004 anyone?
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: text/plain; charset="windows-1252"
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <4CE862C5-DC91-4BFB-A225-018AE96F7339@shinkuro.com>
Date: Thu, 31 Dec 2015 14:42:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <88E82966-315B-4A4C-A813-06F020128AE0@puck.nether.net>
References: <7664F94E-F7A6-4556-B1E6-2DE536A7B7FC@frobbit.se> <5684FCDB.7010009@mnt.se> <A074CA07-691E-41A7-B1D7-33F4ECBED5A9@puck.nether.net> <568579FB.6030702@gmail.com> <56857EC9.9020707@bogus.com> <4CE862C5-DC91-4BFB-A225-018AE96F7339@shinkuro.com>
To: Steve Crocker <steve@shinkuro.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UT4RymG2KHHwOawH67oufDQEoK0>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2015 19:42:07 -0000

> On Dec 31, 2015, at 2:21 PM, Steve Crocker <steve@shinkuro.com> wrote:
> 
> I’ve always assumed the proper place to implement BCP 38 is at the edge of the network.  I’ve also assumed that part of the knowledge one network ought to have about another is whether the other network implements BCP 38 at its edge and requires its peers to do so at their edges and require their peers, etc.  Thus, there ought to be an ever growing collection of networks that have agreed that packets entering their networks have had their source addresses checked at their source.  Checking the source addresses as packets traverse from one tier one network to another or from a tier two network to a tier one network should not be necessary, and I can well understand why this would be a performance issue.

Sure.  The edge of my network may have a /19 behind it though, or it could be a /126.  I also don’t know if a customer later turns up as another providers backup-path and forgets to or doesn’t inform me.  Customers are often reluctant to describe who are in that downstream cone in advance, either because of poor planning, fear or something else.

I may want to drop packets that I can’t return (eg: 1918 type sources).  This is where I’ve tried to focus, to forward fewer ‘bad’ packets.

Instead we have ended up with a policy to have certain port or protocol numbers enter a ‘junk’ queue that gets policed.  I may not need Chargen or NTP to be more than 1% of my network.

- Jared