Re: [OPSEC] comment on 'draft-ietf-opsec-ipv6-implications-on-ipv4-nets'

Fernando Gont <fgont@si6networks.com> Fri, 01 March 2013 05:33 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906EF21F882D for <opsec@ietfa.amsl.com>; Thu, 28 Feb 2013 21:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.541
X-Spam-Level:
X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 NbgMcuYzg3z1 for <opsec@ietfa.amsl.com>; Thu, 28 Feb 2013 21:33:56 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBFD21F8803 for <opsec@ietf.org>; Thu, 28 Feb 2013 21:33:55 -0800 (PST)
Received: from [186.137.77.228] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <fgont@si6networks.com>) id 1UBIag-0002fH-BX; Fri, 01 Mar 2013 06:33:06 +0100
Message-ID: <51303822.50108@si6networks.com>
Date: Fri, 01 Mar 2013 02:09:54 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
References: <2134F8430051B64F815C691A62D9831801380F@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831801380F@XCH-BLV-504.nw.nos.boeing.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "opsec@ietf.org" <opsec@ietf.org>
Subject: Re: [OPSEC] comment on 'draft-ietf-opsec-ipv6-implications-on-ipv4-nets'
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2013 05:33:57 -0000

Hi, Fred,

On 02/27/2013 03:31 PM, Templin, Fred L wrote:
> 
>   "As a result, blocking ISATAP by preventing hosts from
>    successfully performing name resolution for the
>    aforementioned names and/or by filtering packets with
>    specific IPv4 destination addresses is both difficult
>    and undesirable."
> 
> I would like to understand this better. In particular, the
> ISATAP service is by design disabled by disabling name
> resolution for the name "isatap.domainname" and/or by
> disabling the ISATAP router advertisement service. Can
> you say why this would be difficult and undesirable?

Preventing name resolution is virtually impossible, since Windows nodes
not only try to perform such resolution with DNS, but also with LLMNR.
In order to block the latter, you should be able to achieve such
filtering at layer 2 -- and that would be a bit onerous (not to mention
how difficult that would be if fragmentation is employed).

Since you never know what the isata domain names may resolve to, it's
essentially impossible to block isatap packets based on a specific
destination address (you'd need to know such address in advance in order
to create the ACL).

Please do let me know if this clarification has been of any help.

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