Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

"Fred Baker (fred)" <fred@cisco.com> Fri, 15 November 2013 19:23 UTC

Return-Path: <fred@cisco.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 B35AA11E8174 for <v6ops@ietfa.amsl.com>; Fri, 15 Nov 2013 11:23:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.185
X-Spam-Level:
X-Spam-Status: No, score=-110.185 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tvIq7lYVXUJu for <v6ops@ietfa.amsl.com>; Fri, 15 Nov 2013 11:23:07 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05911E810D for <v6ops@ietf.org>; Fri, 15 Nov 2013 11:23:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3915; q=dns/txt; s=iport; t=1384543383; x=1385752983; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ARdo1M13js1ql+5XXlPUPliaD0le4DaMNVo9QzRnRQ4=; b=B1BAalUNirXPGvVwOYwkAkEqi3bYA6YULY3ZUmnpcMSqjoMEDvl2rdOZ fDAwXeBPcqk63nJttp9wDOHM4y7PmaECqUXL8lpRsUtYU8YFygozL22C9 JMISa/fpdUAdLtcrhgmDt+5nRIrpLj5lczfhtN/GkQyy7ZOd6sc3HJVL6 E=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FALVzhlKtJV2Z/2dsb2JhbABZgwc4U78qgSoWdIIlAQEBAwEBAQFiCQsFCwIBCBguIQYLJQIEDgUOh2EDCQYNt00NiUQEjHOCdgeDIIERA5AwgTCERYFrjFWFOIMogio
X-IronPort-AV: E=Sophos; i="4.93,709,1378857600"; d="asc'?scan'208"; a="285481994"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2013 19:23:02 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAFJN2QR013882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 19:23:02 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Fri, 15 Nov 2013 13:23:02 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: "cb.list6" <cb.list6@gmail.com>
Thread-Topic: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
Thread-Index: AQHO4jgZrvtubQWqEEOgPb+wOW623g==
Date: Fri, 15 Nov 2013 19:23:02 +0000
Message-ID: <5FC70D46-B3DE-4398-89A8-8561CDEAC5AA@cisco.com>
References: <201311101900.rAAJ0AR6025350@irp-view13.cisco.com> <528661C5.3060005@forthnet.gr> <2BED1CEF-FBF2-490B-8468-8024BCBEC1F0@cisco.com> <CAD6AjGQxmBn8qURu056bhkNcE0WFd7rwmHP1HryLGHS+zOV0BA@mail.gmail.com>
In-Reply-To: <CAD6AjGQxmBn8qURu056bhkNcE0WFd7rwmHP1HryLGHS+zOV0BA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.121]
Content-Type: multipart/signed; boundary="Apple-Mail=_25EA0458-CAD5-43AC-9A2B-B7D50FBD0DE7"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
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: Fri, 15 Nov 2013 19:23:12 -0000

Well, that's one of the things the draft says. It also describes a security model that the IETF is intended to say is adequate for some purpose. It's that security model that I'm commenting on.

On Nov 15, 2013, at 10:49 AM, cb.list6 <cb.list6@gmail.com>
 wrote:

> On Fri, Nov 15, 2013 at 10:35 AM, Fred Baker (fred) <fred@cisco.com> wrote:
>> 
>> On Nov 15, 2013, at 10:02 AM, Tassos Chatzithomaoglou <achatz@forthnet.gr> wrote:
>> 
>>> So, although i support this, i would like to see a note warning about some of the above dangers and noting that extra caution is to be used when following this.
>> 
>> Thanks.
>> 
>> Again, speaking as a participant.
>> 
>> Where I most scratch my head is that the threat the firewall presumably is intended to defend against, and the asset it is trying to defend, is not usually related to a protocol. If we decide that a given protocol number or port number is "universally OK", such as RFC 6092's comments on ESP/AH/IKE, one can expect port-agile attacks to use that port number for whatever protocol they use. If we say that we want a specified server to act as a listener for a protocol, such as a web server for http/https, that doesn't imply that all devices implementing listeners should be exposed as a matter of policy (if you have a Canon MP620 series printer or a Cisco telephone, and its address is X.X.X.X, open http://X.X.X.X, and ask yourself if that's information you want available to the world).
>> 
>> So, blocking a couple of ports doesn't seem to accomplish much from a security perspective. I'm not sure what I would call "security" in this draft, much less "balanced". What the draft does, as near as I can tell, is give service providers something that somebody called a firewall, so that they can tell their customers that have the presence of a firewall as a market requirement that they are deploying a firewall, but depending on their customers to be dumb enough to not realize that the firewall doesn't secure anything.
>> 
> 
> Network operators who have deployed this strategy outlined in the
> draft have penned the draft, they have to deal with the strain on
> their network and helpdesk calls related to being hacked.
> 
> I believe the point of the draft is to share deployment experience
> that there is no material change to the relevant network provider
> metrics related to those costs of hacking.
> 
> If i understanding the scenario correctly, Swisscom had IPv4 NAT CPE
> deployed with "stateful connection inspection" by default
> 
> They deployed IPv6 on a large scale without "stateful connection
> inspection"  for IPv6 and the relevant metrics of attack traffic and
> helpdesk calls have not changed.
> 
> This is not a matter of theory, this a matter of network operators
> sharing operational experience for the betterment of other network
> operators.
> 
> CB
> 
>> BTW, as chair, I have asked for a security directorate review of this draft.
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>