All of lore.kernel.org
 help / color / mirror / Atom feed
* With regard to processing overlapping fragment packet
@ 2020-05-26  5:47 강유건
  2020-05-26  7:54 ` Michal Kubecek
  0 siblings, 1 reply; 3+ messages in thread
From: 강유건 @ 2020-05-26  5:47 UTC (permalink / raw)
  To: netdev

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

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.

Thank you for reading the long article!

-- Yugeon Kang

-- 

강 유 건 사원

펌킨네트웍스㈜ 개발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

[-- Attachment #2: 82_html_Link0 (1).pcap --]
[-- Type: application/octet-stream, Size: 1460 bytes --]

[-- Attachment #3: rfc5722.PNG --]
[-- Type: image/png, Size: 15381 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: With regard to processing overlapping fragment packet
  2020-05-26  5:47 With regard to processing overlapping fragment packet 강유건
@ 2020-05-26  7:54 ` Michal Kubecek
  2020-05-27  1:30   ` 강유건
  0 siblings, 1 reply; 3+ messages in thread
From: Michal Kubecek @ 2020-05-26  7:54 UTC (permalink / raw)
  To: netdev; +Cc: 강유건

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: With regard to processing overlapping fragment packet
  2020-05-26  7:54 ` Michal Kubecek
@ 2020-05-27  1:30   ` 강유건
  0 siblings, 0 replies; 3+ messages in thread
From: 강유건 @ 2020-05-27  1:30 UTC (permalink / raw)
  To: Michal Kubecek; +Cc: netdev

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-05-27  1:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.