Re: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 - Comments

Francis Dupont <Francis.Dupont@enst-bretagne.fr> Thu, 01 December 2005 12:46 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehnpj-0003ez-D8; Thu, 01 Dec 2005 07:46:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehnph-0003ed-GX for mip6@megatron.ietf.org; Thu, 01 Dec 2005 07:46:42 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15538 for <mip6@ietf.org>; Thu, 1 Dec 2005 07:45:54 -0500 (EST)
Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhoAA-00042J-25 for mip6@ietf.org; Thu, 01 Dec 2005 08:07:51 -0500
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id jB1CkAg21013; Thu, 1 Dec 2005 13:46:10 +0100
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id jB1Ck8FV041344; Thu, 1 Dec 2005 13:46:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200512011246.jB1Ck8FV041344@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Vijay Devarapalli <vijayd@iprg.nokia.com>
Subject: Re: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 - Comments
In-reply-to: Your message of Wed, 30 Nov 2005 16:24:35 PST. <438E42C3.4060502@iprg.nokia.com>
Date: Thu, 01 Dec 2005 13:46:08 +0100
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: Gerardo Giaretta <Gerardo.Giaretta@tilab.com>, mip6@ietf.org
X-BeenThere: mip6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mip6.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip6@ietf.org>
List-Help: <mailto:mip6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip6>, <mailto:mip6-request@ietf.org?subject=subscribe>
Sender: mip6-bounces@ietf.org
Errors-To: mip6-bounces@ietf.org

 In your previous mail you wrote:

   > => IMHO an IKEv2 implementation should perform a proxy DAD when it
   > allocates an address before returning it as it should provide
   > a proxy NDP service (i.e., reply to NS by not-overriding NA).
   > Both should be configurable with by default being on.
   
   okay, but I dont think we should mandate the IKEv2 implementation
   to do proxy DAD.
   
=> we (as the MIP6 WG) should not but we (as the IETF) should.

   >    the authorization check is required. cant be skipped.
   > 
   > => show us where this authorization for the address is required
   > or even mentioned in RFC 2136, PLEASE!
   
   in the security considerations section we have the following.
   
=> this is fully irrelevant as this is *not* from the RFC 2136.

       This
       choice was motivated by a concern for preventing redirection-based
       flooding attacks (see draft-ietf-mip6-ro-sec [19] for more
       information about redirection-based flooding attacks and the role
       preventing them played in the design of Mobile IPv6 route
       optimization security). Exactly as for route optimization, it is
       possible for a node that is the legitimate owner of a DNS FQDN -
       in the sense that it has a security association with the DNS
       server allowing it to perform dynamic DNS update of its FQDN - to
       bind its FQDN to the address of a victim, then redirect large
       volumes of traffic at the victim. The attack may be propagated
       without the owner's knowledge, for example, if the node is
       compromised by malware, or it may be intentional if the node
       itself is the attacker.
   
   if RFC 2136 ignored this, I cant help it.
   
=> the RFC 2136 ignored this and it is in its scope, not in the scope
of the MIP6 WG.

Regards

Francis.Dupont@enst-bretagne.fr

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6