Re: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

HYUN WOOK CHA <hyunwook.cha@samsung.com> Wed, 08 October 2008 00:40 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C86D53A6844; Tue, 7 Oct 2008 17:40:49 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA9E3A6844; Tue, 7 Oct 2008 17:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level:
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfentmvzqSk6; Tue, 7 Oct 2008 17:40:47 -0700 (PDT)
Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 726BF3A681A; Tue, 7 Oct 2008 17:40:47 -0700 (PDT)
Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K8E00LH29WWNN@mailout1.samsung.com>; Wed, 08 Oct 2008 09:41:20 +0900 (KST)
Received: from ep_spt01 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0K8E0011W9WV50@ms7.samsung.com>; Wed, 08 Oct 2008 09:41:19 +0900 (KST)
Content-return: prohibited
Date: Wed, 08 Oct 2008 00:41:19 +0000
From: HYUN WOOK CHA <hyunwook.cha@samsung.com>
Subject: Re: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"
To: Brian Haberman <brian@innovationslab.net>
Message-id: <17818024.401631223426479734.JavaMail.weblogic@epml18>
MIME-version: 1.0
MIME-version: 1.0
X-Priority: 3
Msgkey: 20081008003730718@hyunwook.cha
X-MTR: 20081008003730718@hyunwook.cha
X-EPLocale: ko_KR.windows-1252
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale:
X-EPHeader: ML
X-EPTrCode:
X-EPTrName:
Cc: "narten@us.ibm.com" <narten@us.ibm.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>, "volz@cisco.com" <volz@cisco.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: hyunwook.cha@samsung.com
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

Hello, Brian.

As I presented last IETF 6MAN meeting, our draft aims to provide automatic revocation of DHCPv6 clients in case that invocation of clients can be done in accordance with the RFC2462. Thus, requirement of our security model is that we should not intoduce additional threats to the existing specification and implementations. Since per-interface state variables are managed through timer based algorithm proposed in the draft, illegal RA messages can not stop clients as long as legal RA messages advertise the availability of DHCPv6 service. Also, we proposed two options when state variables are invalidated: 1) DHCPv6 client may refer state variables to decide whether it should keep its operation or not only after all bindings(leases) expires. 2) DHCPv6 client may be stopped immediately at the transition of variables from 1 to 0. With the first option, client can keep its operation even if state variables will be changed to 0 since legal RA messages are absent within lifetimes by any reasons. 

> It would seem quite dangerous to enable/disable DHCPv6 clients 
> arbitrarily based on bit settings in un-protected RA messages.

I agree with your point. We do not have any security methods and just consider using the SEND. 
Regards, 
Joseph

------- Original Message -------
Sender : Brian Haberman<brian@innovationslab.net> 
Date   : 2008-10-08 04:20 (GMT+09:00)
Title  : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

Joseph,
      Do you have a particular security model in mind for giving Router 
Advertisements the power to control software functionality on each node? 
  It would seem quite dangerous to enable/disable DHCPv6 clients 
arbitrarily based on bit settings in un-protected RA messages.

Regards,
Brian


HYUN WOOK CHA wrote:
> Hello, Ted.
> 
> That's correct. I believe that the ability to stop DHCP clients using
> M/O bits in RA is required once they were invoked by M/O bits in RA.
> 
> 
> Joseph
> 
> ------- Original Message ------- Sender : Ted
> Lemon<Ted.Lemon@nominum.com> Date   : 2008-09-30 09:36 (GMT+09:00) 
> Title  : Re: Request for Advices on the draft
> "draft-cha-ipv6-ra-mo-00.txt"
> 
> Joseph, to summarize, it sounds like you believe that the ability to
>  stop DHCP clients broadcasting on a link is a requirement.   And you
>  therefore think that deprecating the M&O bits is not the right 
> answer.   Is that correct?
> 
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------