Re: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05

<Basavaraj.Patil@nokia.com> Tue, 29 November 2011 17:53 UTC

Return-Path: <Basavaraj.Patil@nokia.com>
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 C50DA21F8B64 for <mext@ietfa.amsl.com>; Tue, 29 Nov 2011 09:53:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 X1s-kjSMvxVw for <mext@ietfa.amsl.com>; Tue, 29 Nov 2011 09:53:06 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B77C821F8B61 for <mext@ietf.org>; Tue, 29 Nov 2011 09:53:05 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pATHqWWR027087; Tue, 29 Nov 2011 19:52:32 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Nov 2011 19:52:31 +0200
Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.176]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Tue, 29 Nov 2011 18:52:31 +0100
From: Basavaraj.Patil@nokia.com
To: marc.lampo@eurid.eu, mext@ietf.org
Thread-Topic: [MEXT] feedback on draft-ietf-firewall-[vendor|admin]-05
Thread-Index: AcytpdgEd6e1lIHyScO+9L374FdmaAA3yRcA
Date: Tue, 29 Nov 2011 17:52:30 +0000
Message-ID: <CAFA77A0.16328%basavaraj.patil@nokia.com>
In-Reply-To: <006901ccada5$d8644200$892cc600$@lampo@eurid.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [172.19.59.33]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <FA7E89560668F140AAB3005D7EDC1354@mgd.nokia.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Nov 2011 17:52:31.0990 (UTC) FILETIME=[AB202960:01CCAEBF]
X-Nokia-AV: Clean
Subject: Re: [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: Tue, 29 Nov 2011 17:53:06 -0000

Hi Marco,

In I-D: draft-ietf-mext-mip6-tls we do propose the use of UDP
encapsulation for signaling and traffic between the MN and HA. This would
make the processing and firewall rules simpler (UDP port) as you mentioned
in your email.

-Raj

On 11/28/11 2:15 AM, "ext Marc Lampo" <marc.lampo@eurid.eu> wrote:

>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 mailing list
>MEXT@ietf.org
>https://www.ietf.org/mailman/listinfo/mext