Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00

S Moonesamy <sm+ietf@elandsys.com> Sat, 06 July 2013 00:47 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4412A11E80F3 for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 17:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.577
X-Spam-Level:
X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jKaziNX6NOZ for <v6ops@ietfa.amsl.com>; Fri, 5 Jul 2013 17:47:31 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4031221F9FF9 for <v6ops@ietf.org>; Fri, 5 Jul 2013 17:47:30 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.148.24]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r660l9N7025043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Jul 2013 17:47:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1373071642; bh=VLViFhGQ2sSnPaZ2Svqqhw9d3YMLbYuTfRRX9Cqhpxw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=sTwBX9mOq1r3u40/8OO0ytsJG0l8yr23zW0t0/poPnsoThoBmzu9ryLjIsiCus1d0 81JpxpuVoQeuXE6ZOrrAS5RQWtcIXp0/u0uLyStJJtGuda3TnfEbo3Gl5u30SgAx+G ej8UJacmtD7P+8+AcMjpo8pH+gM4ukpR6/ju99mM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1373071642; i=@elandsys.com; bh=VLViFhGQ2sSnPaZ2Svqqhw9d3YMLbYuTfRRX9Cqhpxw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PuQw2o8rzOva36SEvdA82miMvg+6ridtIb5FbvND9D69NEvyq/H7/HyT2wXlCN/DS C8FU92vsTJ+N6pxZs8mDa3OH+fJmPJ0vaL4zcyN5x/OtQWQShVVvui9ImCHvKXOpL/ yAnmekKK5QwjSFUTRHyLax3paB1qL+NKscPy3z8Q=
Message-Id: <6.2.5.6.2.20130705123350.0c715628@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 05 Jul 2013 13:03:17 -0700
To: David Farmer <farmer@umn.edu>, Arturo Servin <arturo.servin@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <51D6EBDB.3030309@umn.edu>
References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D4CD90.5070005@gmail.com> <6.2.5.6.2.20130703220114.0c8241b8@resistor.net> <51D55CF0.9010301@gmail.com> <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com> <51D6EBDB.3030309@umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Mitigation against IPv6 Router Advertisements flooding - draft-moonesamy-ra-flood-limit-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jul 2013 00:47:32 -0000

Hi Arturo, David,
At 08:52 05-07-2013, David Farmer wrote:
>I think some kind of applicability statement would be a useful 
>addition to the Draft.

 From an IETF Stream perspective it's difficult to assess how to 
write an applicability statement in this context.

>   I'm less worried about a network operators deciding that they 
> don't need to implement RA-Guard because their hosts implement 
> RA-Flood-Limit.  I'm more concerned about OS vendors or 
> implementors deciding they don't need to implement RA-Flood-Limit 
> because they view this as a network operator issue and if only the 
> network operators would just implement RA-Guard then RA-Flood-Limit 
> wouldn't be necessary.

I see.

>I think it needs to be made clear that both RA-Guard and 
>RA-Flood-Limit are independently necessary to ensure both the 
>security and stability of a network and its hosts.

Let me see if I can write some text to discuss the network versus host angle.

>1. RA-Guard or the other the techniques discussed in RFC6104 can 
>effectively prevent RAs sourced from hosts either by malicious 
>activity or simple miss-configuration.  But, RA-Guard can do little 
>to prevent RAs caused by software or hardware bugs within, or 
>miss-configuration of the network itself.

I prefer not to comment about this. :-)

>2. RA-Flood-Limit prevents the consequences of many different RAs 
>being seen by a host, regardless of the source of those RAs.  But, 
>can not distinguish between the source of the RAs, and may allow 
>malicious configuration of the host.

Yes.

>3. Therefore, implementation of BOTH RA-Guard and RA-Flood-Limit are 
>necessary to ensure BOTH the security and stability of a network and its hosts.

I think that the above looks at the proposal as a solution to the RA 
flooding problem whereas the scope of the proposal is a mitigation to 
a problem which a host may encounter.

At 09:06 05-07-2013, Arturo Servin wrote:
>     I also agree with you that both RA-Guard and RA-Flood-Limit are
>necessary. I think those statements should be added to the draft.

Please see the comment above about the scope.

Regards,
S. Moonesamy