All of lore.kernel.org
 help / color / mirror / Atom feed
From: 강유건 <yugun819@pumpkinnet.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: netdev@vger.kernel.org
Subject: Re: With regard to processing overlapping fragment packet
Date: Wed, 27 May 2020 10:30:42 +0900	[thread overview]
Message-ID: <CALMTMJLJYP=FSVFhwLqBLuKC6jNk-Bas1jjkJM+OvuNkt5jETQ@mail.gmail.com> (raw)
In-Reply-To: <20200526075417.n2xdtzpwnpu3vzxx@lion.mk-sys.cz>

Thank you for explaining in detail and letting me know the website.

thanks to you, I learned a little about how to RFC works.


2020년 5월 26일 (화) 오후 4:54, Michal Kubecek <mkubecek@suse.cz>님이 작성:
>
> On Tue, May 26, 2020 at 02:47:25PM +0900, 강유건 wrote:
> > Hello
> >
> > Actually, I'm not sure if it's right to send mail here.
> >
> > I'm testing ipv6ready Self Test 5.0.4 using linux-4.19.118 kernel.
> > ( https://www.ipv6ready.org.cn/home/views/default/resource/logo/phase2-core/index.htm
> > )
> >
> > Test failed in 82. Part B: Reverse Order Fragments ( Link-Local ) in
> > Section 1. spec
> >
> > In test 82, source transmits 3 fragment packets in reverse order that
> > are originally a icmpv6 packet.
> > There is an overlapping interval between the 2nd and 3rd packet.
> >
> > The test requires the destination MUST drop all packets and respond nothing,
> > but the dest replies Time Exceeded / Reassembly Timeout.
> >
> > I've read some /net/ipv6 codes and think when the kernel receives the
> > 2nd packet ( overlapping occurs ), it drops 3rd and 2nd packets and
> > recognizes the 1st packet as a new fragment packet.
> > ( Is it right ? )
> >
> > In RFC5722, when a node receives the overlapping fragment, it MUST
> > discard those not yet received. (  In this case, I think it applies to
> > 1st packet )
> >
> > Please let me know if I misunderstood RFC or if it wasn't implemented
> > in the kernel.
>
> You understood the requirement of the RFC correctly but the problem is
> that implementing it would be too complicated, would make the
> implementation susceptible to DoS attacks and could even result in
> dropping legitimate (new) fragments. Therefore an erratum to RFC 5722
> was accepted which drops the requirement to also drop fragments not
> received yet:
>
>   https://www.rfc-editor.org/errata/eid3089
>
> Michal



-- 


강 유 건 사원

펌킨네트웍스㈜ 개발1팀

08380 서울시 구로구 디지털로31길 20 에이스테크노타워 5차 405호

Direct: 070-4263-9937

Mobile: 010-9887-3517

E-mail: yugun819@pumpkinnet.com

Tel: 02-863-9380, Fax: 02-2109-6675

www.pumpkinnet.co.kr

      reply	other threads:[~2020-05-27  1:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-26  5:47 With regard to processing overlapping fragment packet 강유건
2020-05-26  7:54 ` Michal Kubecek
2020-05-27  1:30   ` 강유건 [this message]

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='CALMTMJLJYP=FSVFhwLqBLuKC6jNk-Bas1jjkJM+OvuNkt5jETQ@mail.gmail.com' \
    --to=yugun819@pumpkinnet.com \
    --cc=mkubecek@suse.cz \
    --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.