All of lore.kernel.org
 help / color / mirror / Atom feed
From: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
To: Hangbin Liu <liuhangbin@gmail.com>
Cc: hideaki.yoshifuji@miraclelinux.com,
	network dev <netdev@vger.kernel.org>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: [PATCHv2] net/ipv6: add sysctl option accept_ra_hop_limit
Date: Tue, 28 Jul 2015 12:58:08 +0900	[thread overview]
Message-ID: <55B6FDD0.4020904@miraclelinux.com> (raw)
In-Reply-To: <CAPwn2JSk0P8n+aSxTGiU0Q2RSSbZ52NVZxOS+yURpor2YQVySQ@mail.gmail.com>

Hi,

Hangbin Liu wrote:
> 2015-07-28 7:50 GMT+08:00 YOSHIFUJI Hideaki/吉藤英明
> <hideaki.yoshifuji@miraclelinux.com>:
>> Hi,
>>
>> Hangbin Liu wrote:
>>> Commit 6fd99094de2b ("ipv6: Don't reduce hop limit for an interface")
>>> disabled accept hop limit from RA if it is higher than the current hop
>>> limit for security stuff. But this behavior kind of break the RFC definition.
>>>
>>> RFC 4861, 6.3.4.  Processing Received Router Advertisements
>>>    If the received Cur Hop Limit value is non-zero, the host SHOULD set
>>>    its CurHopLimit variable to the received value.
>>>
>>> So add sysctl option accept_ra_hop_limit to let user choose whether accept
>>> hop limit info in RA.
>>>
>>
>> How about introducing "minimum hop limit", instead?
> 
> Hi Yoshifuji,
> 
> This is a good idea. Maybe this can be another sysctl option?
> 
> The minimum hop limit can be an enhancement of the security issue, then we will
> not only increase the hop limit, but also could decrease it in the
> range of values we
> accept.
> 
> On the other hand, with this patch, we can enable, disable or partly
> enable accept
> hop limit. If we only use "minimum hop limit", people could not use a static hop
> limit value.
> 
> May be we use a “hop limit range" instead? How do you think?

I think name of sysctl is the same as you suggested and change the
semantics.  default value is 0 to accept all hotlimit value
as before and people can set it to 32 (for example) to reject
too-small hoplimit (0-31).

--yoshfuji

> 
> Thanks
> Hangbin
> 
>>
>> |commit 6fd99094de2b83d1d4c8457f2c83483b2828e75a
>> |Author: D.S. Ljungmark <ljungmark@modio.se>
>> |Date:   Wed Mar 25 09:28:15 2015 +0100
>> |
>> |    ipv6: Don't reduce hop limit for an interface
>> :
>> |    RFC 3756, Section 4.2.7, "Parameter Spoofing"
>> |
>> :
>> |   >   As an example, one possible approach to mitigate this threat is to
>> |    >   ignore very small hop limits.  The nodes could implement a
>> |    >   configurable minimum hop limit, and ignore attempts to set it below
>> |    >   said limit.

-- 
Hideaki Yoshifuji <hideaki.yoshifuji@miraclelinux.com>
Technical Division, MIRACLE LINUX CORPORATION

  reply	other threads:[~2015-07-28  3:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-27  6:35 [PATCHv2] net/ipv6: add sysctl option accept_ra_hop_limit Hangbin Liu
2015-07-27 23:50 ` YOSHIFUJI Hideaki/吉藤英明
2015-07-28  3:05   ` Hangbin Liu
2015-07-28  3:58     ` YOSHIFUJI Hideaki [this message]
2015-07-29  2:00       ` Hangbin Liu
2015-07-29  2:14         ` YOSHIFUJI Hideaki
2015-07-29  9:58           ` Hangbin Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55B6FDD0.4020904@miraclelinux.com \
    --to=hideaki.yoshifuji@miraclelinux.com \
    --cc=hannes@stressinduktion.org \
    --cc=liuhangbin@gmail.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.