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

S Moonesamy <sm+ietf@elandsys.com> Thu, 04 July 2013 01:20 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 B83AB21F9A0A for <v6ops@ietfa.amsl.com>; Wed, 3 Jul 2013 18:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LM4UQedX6dXz for <v6ops@ietfa.amsl.com>; Wed, 3 Jul 2013 18:20:56 -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 D265821F9A05 for <v6ops@ietf.org>; Wed, 3 Jul 2013 18:20:55 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.149.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r641Kghh012194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Jul 2013 18:20:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372900853; bh=v5m+HUDiJrgS7NcUCXLNk8sk0WnmeKpCLsOx0H97DK8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SlpVyocWRxRWErEagWtCVWOT83WLzsVV2jDqWoUePSSt4PsTbbxK2FqngKrj/aHOX UqHFYlpZYhhFCwrTasj3wLVKGXg4Z/lDA295OGw8bvoAY8efD6lhsSfpM0HYrWS8zs ZqO7cXLnKP+10u/QbeBZlXPNKp7IEafmz4cJG7Vs=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372900853; i=@elandsys.com; bh=v5m+HUDiJrgS7NcUCXLNk8sk0WnmeKpCLsOx0H97DK8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QpHQVQYzClVxvhLH+luK/FHsPepIse4Nz8SNajZ5BJp7xRPvs+A88PmOm16syiF8y Jzj9x/yFwKRlb9DRfNorcFEL44TXzokI7lKpBwL1264xb+nfJY+HToAxEuWY9tN6nV bDfXHmPWF6ianEWyZcfCNtGa4wf4QWC4pzKr3gh4=
Message-Id: <6.2.5.6.2.20130703130208.0dd80478@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 03 Jul 2013 16:05:27 -0700
To: David Farmer <farmer@umn.edu>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <51D45EC2.6080807@umn.edu>
References: <6.2.5.6.2.20130702145424.0af37160@elandnews.com> <51D3ABE4.9030901@umn.edu> <6.2.5.6.2.20130702233628.0bc7c778@elandnews.com> <51D45EC2.6080807@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: Thu, 04 Jul 2013 01:20:58 -0000

Hi David,
At 10:26 03-07-2013, David Farmer wrote:
>I didn't say you had to deploy RFC6105 complaint devices, I said you 
>need that, "or the other mitigation techniques discussed in section 
>3 of [RFC6104]."  In the particular case you describe, I'd recommend 
>the technique described in section 3.5 of RFC6104; Setting the valid 
>RA to a Router Preference of "High", this has little or no cost and 
>is relatively effective, especailly with the techniques described in 
>this draft.

The reference to RFC 6104 is there so that people can read that 
document and decide about which mitigation technique is better suited 
to their needs.  Setting the valid RA to a Router Preference of 
"High" is an operational decision instead of an implementation decision.

>I agree, I'm just saying you should be more explicit about what this 
>does and doesn't do.  Maybe add the following as an additional 
>paragraph to the security considerations
>  section;
>
>    However, without deployment of RA Guard mechanisms as described in
>    [RFC6105] or the other mitigation techniques discussed in section 3
>    of [RFC6104] it is still possible for a malicious attacker to
>    disrupt access to a network or cause traffic to be diverted.

The above sounds like an operational choice.  It may be better to 
keep the different decisions separate.

>Thanks, I better understand the intended behaviour now.  I suggest 
>the following text for section 2, to more clearly describe the 
>intended behaviour.
>
>    A host will silently discard any Router Advertisement that cause one
>    of the following configurable limits to be exceeded.  However, Router
>    Advertisements that only refresh previously learned configuration
>    information are processed.  Suggested default values are specified
>    making it unnecessary to configure these variables for most typical
>    situations.

Thanks for suggesting text.  I would like to read the off-list 
comments I received and then figure out how to add the suggested changes.

>My intent is not sensationalism, its fair warning.  I don't want a 
>naive users or

I don't think that was your intent.  I meant that I am looking at 
what the code does instead of other angles that might be misleading.

>  enterprise network operator reading this and thinking that if 
> their hosts implement this all their RA issues are solved.  If you 
> added the paragraph I suggest above to the security consideration 
> section I think it would provide the explicit and necessary fair 
> warning I'm looking for.

I agree that a fair warning would be appropriate.  Someone else 
already suggested changes to the Security Considerations section.  I 
will incorporate them in the next revision.

Regards,
S. Moonesamy