[MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05
"Marc Lampo" <marc.lampo@eurid.eu> Mon, 28 November 2011 08:15 UTC
Return-Path: <marc.lampo@eurid.eu>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50F11E808F for <mext@ietfa.amsl.com>; Mon, 28 Nov 2011 00:15:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.001
X-Spam-Level: ***
X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, MSGID_MULTIPLE_AT=1.449, RDNS_NONE=0.1]
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 cYIu2btUWcL1 for <mext@ietfa.amsl.com>; Mon, 28 Nov 2011 00:15:15 -0800 (PST)
Received: from cuda.eurid.eu (unknown [62.41.4.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2283121F8BC3 for <mext@ietf.org>; Mon, 28 Nov 2011 00:15:13 -0800 (PST)
X-ASG-Debug-ID: 1322468109-02dadd0667a0650001-NRjzFm
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by cuda.eurid.eu with ESMTP id wSEK8TkgmgTPmswQ for <mext@ietf.org>; Mon, 28 Nov 2011 09:15:09 +0100 (CET)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 4EC8DE4056 for <mext@ietf.org>; Mon, 28 Nov 2011 09:15:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbUzc1nBqasl for <mext@ietf.org>; Mon, 28 Nov 2011 09:15:09 +0100 (CET)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 3DEECE4050 for <mext@ietf.org>; Mon, 28 Nov 2011 09:15:09 +0100 (CET)
From: Marc Lampo <marc.lampo@eurid.eu>
To: mext@ietf.org
Date: Mon, 28 Nov 2011 09:15:09 +0100
X-ASG-Orig-Subj: feedback on draft-ietf-firewall-[vendor|admin]-05
Message-ID: <006901ccada5$d8644200$892cc600$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: AcytpdgEd6e1lIHyScO+9L374FdmaA==
Content-Language: en-za
X-Originating-IP: [172.20.5.51]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1322468109
X-Barracuda-URL: http://10.31.100.125:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Subject: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2011 08:15:16 -0000
Hello, Looking at the list archive, I see no comments on these drafts, published October 17th. Nor do I find any traces of discussions on IETF-82. However, from a security point of view, I do have a remark. In both drafts, the "Security Considerations" state : (quoting extracts) ... "recommends a liberal setting of firewall rules" ... ... "some malicious traffic may be permitted" ... ... "allow the initiation of Denial of Service attacks against Mobile IPv6 capable nodes" ... Is this acceptable ? Being concerned with security, I'd say that these statements as "Security Considerations" might lead to the conclusion that these mobility extensions cannot be used, in practice ?! We hear that mobile networks might be the first to be IPv6 only (if there aren't already such networks around) --> IPv6 only in mobile nets : the target for Mobility Extensions We see that more and more banks offer clients for smartphones for Internet banking --> the "correspondent node" might very well be in some bank's DMZ ??? if they, bank security admins, will accept to setup security devices in such a way that "firewall rules are liberal" and "potentially allow that DOS attacks are started" ??? It is my impression that, to put mobility information so "deep" in the stack - as "extension header" with IPPROTO_NONE in the next header field - implies that security infrastructure will need quite some CPU resources to work its way through them. Wouldn't it have been wiser to assign a (UDP ?) portnumber to the Mobility "application" ? Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium marc.lampo@eurid.eu http://www.eurid.eu
- [MEXT] feedback on draft-ietf-firewall-[vendor|ad… Marc Lampo
- Re: [MEXT] feedback on draft-ietf-firewall-[vendo… Basavaraj.Patil
- Re: [MEXT] feedback on draft-ietf-firewall-[vendo… Suresh Krishnan