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

Vijay Devarapalli <vijayd@iprg.nokia.com> Thu, 01 December 2005 00:25 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 1EhcG8-0007jn-Jx; Wed, 30 Nov 2005 19:25:12 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhcG7-0007jd-3U for mip6@megatron.ietf.org; Wed, 30 Nov 2005 19:25:11 -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 TAA22839 for <mip6@ietf.org>; Wed, 30 Nov 2005 19:24:24 -0500 (EST)
Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhcaT-0006O8-NK for mip6@ietf.org; Wed, 30 Nov 2005 19:46:15 -0500
Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jAUNoJN29686; Wed, 30 Nov 2005 15:50:19 -0800
X-mProtect: <200511302350> Nokia Silicon Valley Messaging Protection
Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdls7llV; Wed, 30 Nov 2005 15:50:17 PST
Message-ID: <438E42C3.4060502@iprg.nokia.com>
Date: Wed, 30 Nov 2005 16:24:35 -0800
From: Vijay Devarapalli <vijayd@iprg.nokia.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
Subject: Re: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 - Comments
References: <200511302348.jAUNmUic037946@givry.rennes.enst-bretagne.fr>
In-Reply-To: <200511302348.jAUNmUic037946@givry.rennes.enst-bretagne.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Content-Transfer-Encoding: 7bit
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

Francis Dupont wrote:
>  In your previous mail you wrote:
> 
>    it was done this way to require minimal changes to RFC 3775 and
>    the IKEv2 implementation on the HA. an IPsec implementation
>    typically does not perform proxy DAD when allocating an address
>    and returning it in the CFG_REPLY message.
>    
> => 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.

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

Vijay


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