Re: [secdir] Secdir review of draft-ietf-multimob-pmipv6-source

"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Wed, 26 March 2014 21:07 UTC

Return-Path: <prvs=1551fcbe4=schmidt@informatik.haw-hamburg.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE4D1A03D9; Wed, 26 Mar 2014 14:07:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.56
X-Spam-Level:
X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnrWvUIy5HHQ; Wed, 26 Mar 2014 14:07:09 -0700 (PDT)
Received: from mx6.haw-public.haw-hamburg.de (mx6.haw-public.haw-hamburg.de [141.22.6.3]) by ietfa.amsl.com (Postfix) with ESMTP id BC94E1A03D1; Wed, 26 Mar 2014 14:07:08 -0700 (PDT)
Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail6.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 26 Mar 2014 22:07:06 +0100
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id 6FDE310679D7; Wed, 26 Mar 2014 22:07:06 +0100 (CET)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21793-09; Wed, 26 Mar 2014 22:07:05 +0100 (CET)
Received: from [141.22.28.186] (unknown [141.22.28.186]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 2A2BC10679CF; Wed, 26 Mar 2014 22:07:04 +0100 (CET)
Message-ID: <53334175.8080807@informatik.haw-hamburg.de>
Date: Wed, 26 Mar 2014 22:07:01 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Radia Perlman <radiaperlman@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-multimob-pmipv6-source.all@tools.ietf.org
References: <CAFOuuo4wkvJduL2-6NOyzB_Bv5QrETMwONgC2aVdcFwzRQ-Njg@mail.gmail.com>
In-Reply-To: <CAFOuuo4wkvJduL2-6NOyzB_Bv5QrETMwONgC2aVdcFwzRQ-Njg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/dqAebyg0IRwXWGcHkWYkPdyBQls
X-Mailman-Approved-At: Wed, 26 Mar 2014 15:39:13 -0700
Subject: Re: [secdir] Secdir review of draft-ietf-multimob-pmipv6-source
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 21:07:12 -0000

Dear Radia,

thanks for your review and please apologize our late reply.

Please see answers inline.

On 18.03.2014 05:17, Radia Perlman wrote:
>
>
>
> On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman <radiaperlman@gmail.com
> <mailto:radiaperlman@gmail.com>> wrote:
>
>     I have reviewed this document as part of the security directorate's
>     ongoing effort to review all IETF documents being processed by the
>     IESG.  These comments were written primarily for the benefit of the
>     security area directors.  Document editors and WG chairs should treat
>     these comments just like any other last call comments.
>
> This document combines mobile IPv6 with multicast.  It's unnecessarily
> difficult to read.  There should be a section upfront expanding all the
> acronyms, at the very least.  For instance, MLD, PMIPv6, PIM, MAG, HNP.
>   Some of these (like MAG) are expanded in the text the first time they
> are used, but most are not, and people aren't necessarily going to
> remember it because of seeing it once, and there's no downside to having
> a section in the introduction called "acronyms".
>

I'm sorry that reading was troublesome. We have taken up your suggestion 
to add the list of acronyms. However, this draft builds on two rather 
large subject areas, Multicast and Mobility Management. Retelling only 
the core ideas of the protocols involved in this work would extend the 
document to a rather unpleasant volume ...

> It also wouldn't hurt to explain "proxy mobile IPv6 domains"  (not just
> expand the acronym PMIPv6).
>

Proxy Mobile IPv6 Domain = region of PMIPv6 deployment ... this is a 
very common term in our area. Considering the target audience of this 
document ( i.e., people who deploy or implement PMIPv6), I would rather 
not burden the document with corresponding explanations.

> I admit I don't completely understand this document, because I didn't
> want to have to read all the other documents that this thing assumes you
> understand, but I think I get the general idea.
>
> I think the security considerations section covers most of the
> downsides, but it doesn't talk about how multicast in general can
> amplify DOS packets.  And with mobility, there are two problems with
> having a proxy sending the multicast (unless it's tunneled, which would
> be OK).  If packets with an IP source address can come from a different
> location, then loops won't be detected (the security considerations
> section mentions that), but also, it's harder for the infrastructure to
> filter out packets from forged IP addresses.
>

The issue you raise (changing source IP addresses) is present at the 
early MIPv4 protocol. In contrast, mobile senders in PMIPv6 tunnel their 
packets to a mobility anchor, the LMA, and thus never need to change 
their source address. Consequently, there is no additional threat 
introduced from topologically invalid or unstable IP addresses. Ingress 
or egress filtering can be applied with PMIPv6 just as in the fixed 
Internet.

Changes to the document as described above will be part of the next 
submission.

Best regards,

Thomas
-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °