Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

Warren Kumari <warren@kumari.net> Mon, 20 August 2012 08:54 UTC

Return-Path: <warren@kumari.net>
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 E795821F8691; Mon, 20 Aug 2012 01:54:40 -0700 (PDT)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY0JIDb62JA1; Mon, 20 Aug 2012 01:54:40 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id BA3F221F8682; Mon, 20 Aug 2012 01:54:36 -0700 (PDT)
Received: from [192.168.202.132] (unknown [74.125.121.33]) by vimes.kumari.net (Postfix) with ESMTPSA id AE6FA1B4085C; Mon, 20 Aug 2012 04:54:35 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="windows-1252"
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org>
Date: Mon, 20 Aug 2012 04:11:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF5CA73B-5535-4ADC-9D95-6468F6413E1A@kumari.net>
References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> <EDA14A02-F441-44AA-B54A-FE0FE8C8C5B8@kumari.net> <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org>
To: Lee Howard <lee@asgard.org>
X-Mailer: Apple Mail (2.1278)
Cc: 'Fernando Gont' <fgont@si6networks.com>, 'v6ops v6ops WG' <v6ops@ietf.org>, opsec@ietf.org
Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets
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: Mon, 20 Aug 2012 08:54:41 -0000

On Aug 17, 2012, at 11:15 AM, Lee Howard wrote:

>>>> -       1.0 please avoid all discussion about NAPT being
> =91minimal/simpl
>>> e=92 security, the days of scanning are over and have been replaced by
>>> malw are download/email propagated
>>> 
>>>> This is demonstrably false, and I can send you logs of scanning
>>>> attempts
>>> foiled by NAPT.  NAT is crap security, but it=92s not zero security.
>>> 
>>> Heretic!
>>> 
>>> Actually, I'd go so far as to drop the "crap" from the above -- while
>>> it is n't "real" security (whatever that means) it has become cool to
>>> simply beat  on the NAT.
>> 
>> But the problem is that people think they need "NAT" as opposed to a
> "stateful firewall with
>> default allow out all, block in all".
>> NAPT effectively establishes the latter + munges with addresses and ports.
> It's the state table
>> not the address/port translation that stops scans.
> 
> That is true, but is not a flaw in the document.  
> The offending text is:
> Finally,
>   some transition/co-existence mechanisms (notably Teredo) are designed
>   to traverse Network Address Translators (NATs), which in many
>   deployments provide a minimum level of protection by only allowing
>   those instances of communication that have been initiated from the
>   internal network.  Thus, these mechanisms might cause an internal
>   host with otherwise limited IPv4 connectivity to become globally
>   reachable over IPv6, therefore resulting in increased (and possibly
>   unexpected) host exposure.  That is, the aforementioned technologies
>   might inadvertently allow incoming IPv6 connections from the Internet
>   to hosts behind the organizational firewall.
> 
> Would you be happy if it said:
>   to traverse Network Address Translators (NATs), which, by keeping a
>  state table and only allowing inbound packets to hosts which have
>  established outbound communication, provides a minimum level of
> protection. . . 
> 
<no-hats>

Personally I'm fine with either…. 

I was just mumbling, don't have any particularly strong feelings on this…

</no-hats>


> I don't think a more thorough discussion of the different risk profiles of
> full
> cone versus symmetric NAT, etc., is warranted here.  I absolutely agree that
> 
> networks should have a stateful firewall.  Would you say that a stateful
> firewall is *even more important* now (with IPv6 ramping up) than it ever
> was before?   
> 
>> Stateless NAT44 or NAT66 doesn't stop scans.
> 
> True.  How is that relevant to a discussion of how unintentional IPv6 may
> affect
> IPv4 networks?
> 
>> As for the secretary's desktop how many of them would be owned if LSR was
> being used to
>> scan 192.168/16 though the NAT box?
> 
> Fewer than if it were even easier.  Again, not really the point of the
> document.
> 
> Lee
> 
> 
>> 
>> Mark
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> 
> 
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
> 

-- 
"He who laughs last, thinks slowest." 
    -- Anonymous