netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: Duan Jiong <djduanjiong@gmail.com>
Cc: Duan Jiong <duanj.fnst@cn.fujitsu.com>,
	davem@davemloft.net, netdev@vger.kernel.org,
	hannes@stressinduktion.org,
	"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>
Subject: Re: [PATCH  v3 0/6] ipv6: Do route updating for redirect in ndisc layer
Date: Tue, 17 Sep 2013 11:00:07 +0200	[thread overview]
Message-ID: <52381A17.7080309@redhat.com> (raw)
In-Reply-To: <523710CC.1090404@gmail.com>

On 09/16/2013 04:08 PM, Duan Jiong wrote:
> 于 2013/9/16 20:22, Daniel Borkmann 写道:
>> On 09/16/2013 01:47 PM, Duan Jiong wrote:
>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>
>>> the ip6_redirect() could be replaced with
>>> ip6_redirect_no_header(), we could always use ip6_redirect()
>>> for route updating in ndisc layer and use the data of the
>>> redirected header option just for finding the socket to be
>>> notified and then notify user in protocols' err_handler.
>> If I get this right, it seems to me that this patchset actually consists of two
>> different kind of changes:
>>
>> 1) Not notifying user space on ICMP redirects (net material)
>> 2) Simplify code for updating route in ndisc layer instead of error handlers (net-next)
>>
>> Also, you do the *actual* change in the very last patch, which means that from
>> patch 1 to 5 we're in an inconsistent and buggy state unless we also apply patch
>> number 6. It should actually be the other way around, that you first do the actual
>> change and then migrate users (also commit messages are quite terse).
> 
> I make the patch set on net tree, not on net-next. Maybe those
> things should be done in two patch sets.
> 
>> Moreover, just looking at the SCTP part (sctp_err_lookup() function) ...
>>
>> /* RFC 4960, Appendix C. ICMP Handling
>>   *
>>   * ICMP6) An implementation MUST validate that the Verification Tag
>>   * contained in the ICMP message matches the Verification Tag of
>>   * the peer.  If the Verification Tag is not 0 and does NOT
>>   * match, discard the ICMP message.  If it is 0 and the ICMP
>>   * message contains enough bytes to verify that the chunk type is
>>   * an INIT chunk and that the Initiate Tag matches the tag of the
>>   * peer, continue with ICMP7.  If the ICMP message is too short
>>   * or the chunk type or the Initiate Tag does not match, silently
>>   * discard the packet.
>>   */
>>   
>> ... it seems to me that we would simply ignore such RFC requirements with
>> your patch for the sctp_v6_err() part.
>>
>> Care to elaborate? ;-)
> 
> Sorry, i didn't notice that.
> 
> According to the RFC requirements, it suggests that we can't update
> route for redirect in ndisc layer before calling into sctp_err_lookup(),
> because we must verify the ICMP Message. Now maybe we update route for
> redirect in ndisc layer is wrong.

Looking further into RFC4960 [1] ... it says:

Appendix C.  ICMP Handling

   Whenever an ICMP message is received by an SCTP endpoint, the
   following procedures MUST be followed to ensure proper utilization of
   the information being provided by layer 3.

   ICMP1) An implementation MAY ignore all ICMPv4 messages where the
          type field is not set to "Destination Unreachable".

   ICMP2) An implementation MAY ignore all ICMPv6 messages where the
          type field is not "Destination Unreachable", "Parameter
          Problem", or "Packet Too Big".
   ...

So this basically means that only packets in step 2 are interesting for us here,
we *may* ignore the rest. The verification comes at step 6, so we may have
ignored the packet first. ;-) Therefore, I think your proposal should not be an
issue for SCTP.

I'd however prefer that your patch handles this similarly as in sctp_v4_err(),
so that in the default switch-case, we just go to out_unlock.

In any case, your commit message would need to be more elaborate and reflect
"why" it is okay/safe to change that in SCTP or other cases, preferably with
reference to the RFC. Otherwise, looking at the Git history in future will just be
confusing as it won't clarify why it was reasonable doing so this way.

  [1] http://tools.ietf.org/html/rfc4960#appendix-C

  reply	other threads:[~2013-09-17  9:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16 11:47 [PATCH v3 0/6] ipv6: Do route updating for redirect in ndisc layer Duan Jiong
2013-09-16 11:49 ` [PATCH 1/6] ipv6: del the statements for updating route in, (dccp|tcp|sctp)_v6_err Duan Jiong
2013-09-16 12:31   ` Duan Jiong
2013-09-16 11:51 ` [PATCH v3 2/6] ipv6: just match on ICMPV6_PKT_TOOBIG in those err_handle Duan Jiong
2013-09-16 11:52 ` [PATCH v3 3/6] ipv6: del statements for dealing with NDISC_REDIRECT Duan Jiong
2013-09-16 11:52 ` [PATCH 4/6] ip6tnl: move route updating for redirect to ndisc layer Duan Jiong
2013-09-16 11:53 ` [PATCH v3 5/6] ipv6: modify the err to 0 when dealing with, NDISC_REDIRECT Duan Jiong
2013-09-16 11:53 ` [PATCH v3 6/6] ipv6: Do route updating for redirect in ndisc layer Duan Jiong
2013-09-16 12:22 ` [PATCH v3 0/6] " Daniel Borkmann
2013-09-16 14:08   ` Duan Jiong
2013-09-17  9:00     ` Daniel Borkmann [this message]
2013-09-17 13:52     ` Hannes Frederic Sowa
2013-09-16 12:41 ` Duan Jiong

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=52381A17.7080309@redhat.com \
    --to=dborkman@redhat.com \
    --cc=davem@davemloft.net \
    --cc=djduanjiong@gmail.com \
    --cc=duanj.fnst@cn.fujitsu.com \
    --cc=hannes@stressinduktion.org \
    --cc=linux-sctp@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).