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

S Moonesamy <sm+ietf@elandsys.com> Fri, 05 July 2013 04:09 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 265E821F8EEA for <v6ops@ietfa.amsl.com>; Thu, 4 Jul 2013 21:09:38 -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=[AWL=0.000, 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 GsJ5xnXdI7K5 for <v6ops@ietfa.amsl.com>; Thu, 4 Jul 2013 21:09:37 -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 402C221F93E5 for <v6ops@ietf.org>; Thu, 4 Jul 2013 21:09:36 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.134.75]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r6549Gu9026477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2013 21:09:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372997368; bh=FjgwU0Nf74edDOTGIi8/l2urM1t2RD6Z98egrJDrwow=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JMU4yHp7voEJnLC0SQgHcWIGRfkxjgD/ejgJXzL9LXQqrit0jMXGUn1fmOG+HLvVj EfCCWgcGUhb/MfQN/L55ltkFN7p0dZ3Fns2QkNPdXnLvoVHyZPrye4OtlSANqsCsfv XiZXRHSkoVch92PY7UxjSdMB1dMvIEMsKeAEFcuc=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372997368; i=@elandsys.com; bh=FjgwU0Nf74edDOTGIi8/l2urM1t2RD6Z98egrJDrwow=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YL5D9mK8hiWdyuXljJoRootSexLxKU+OvCKs08OkUt16hsLoGayQURueFQxhpcp0y L7cJlzTMYCdCKsVJUm9gPS1Us2WhSlHnPrWWXyRzD3hofFHqYXqrpx5NMfw2VtTJvJ t2xreKW5M6rLNAi8JuuVrKyjsVmeUuB9iEujppPs=
Message-Id: <6.2.5.6.2.20130704192850.0d06e8b8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 04 Jul 2013 20:27:19 -0700
To: Arturo Servin <arturo.servin@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <51D55CF0.9010301@gmail.com>
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>
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: Fri, 05 Jul 2013 04:09:38 -0000

Hi Arturo,
At 04:30 04-07-2013, Arturo Servin wrote:
>     Sorry, I should have said "Or are these recommendations orthogonal
>to a network applying RA Guard?"

Yes.

>     I think the ansewer is still yes. But for that reason I think that
>you should mention that this is an add-on to RA Guard (not instead of,
>not criticizing it) and it is intended to provide some security
>mechanisms to the host when the network administrator do not have this
>capability (RA-Guard) in its network.

I think that we are looking at this from two different angles.  I can 
look at this in terms of:

  (a) how does the network protect the host

  (b) how is the host protected

If there is a protection for (a), for example, Router Advertisement 
Guard, (b) might not be much of a problem.  If the host is protected, 
the question being asked is whether (a) is needed or not.  I am not 
trying to answer that question as there is existing code for doing 
(b) and that is what the draft is talking about.  What the person 
writing the code for the host may wish to say is that their system 
provides for the limits mentioned in draft-moonesamy-ra-flood-limit-00.

>     In the end, having RA-Guard could solve enteraly this problem, but
>when it is not provided by the network the host should have mechanisms
>to defend itself. Then is when your draft applies. Does it make sense my
>comment?

Yes, I understood what you wrote.  In my opinion it depends on your 
security posture.  Some people may prefer to put security closer to 
the end whereas others might find it better to do it centrally.  RFC 
6104 discusses about scenarios and different methods to mitigate 
against rogue Router Advertisements.  In my opinion that is where the 
above is more relevant.  What the code does is to prevent the host it 
is running on from crashing.

Regards,
S. Moonesamy