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

From: Radia Perlman <[email-masked]>
Date: Mon, 17 Mar 2014 21:17:51 -0700

On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman <[email-masked]>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".

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

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.

Radia

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 26 Mar 2014 22:07:01 +0100

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>   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 ...

> 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
> 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 °