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

[David Farmer <[e-mail]>]

On 7/4/13 22:27 , S Moonesamy wrote:
> 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.

I think some kind of applicability statement would be a useful addition 
to the Draft.  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 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.

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.

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.

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.

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

I disagree, RA-Guard can effectively deal with RA-Floods caused by hosts 
either through malicious activity or miss-configuration, but can not 
necessarily deal with RA-Floods caused by miss-configuration or bugs 
within the network itself.

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

Security posture is only part of the issue, this is both a security and 
stability issue, that needs both host based and network based mitigation 
strategies.  Neither, RA-Guard or RA-Flood-Limit can ensure both the 
stability and security of a network and it hosts independently, they are 
complementary strategies, and are both necessary for a complete 
solution.  I think it is important for the Draft makes this point one 
way or another.

Thanks

-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================