netdev - RE: IPV4: Enable IP_ID sequencing for all traffic (inquiring mindswant to know why its set to zero)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 Jul 2008 14:16:49 -0700
From:	"Templin, Fred L" <Fred.L.Templin@...ing.com>
To:	"David Miller" <davem@...emloft.net>, <rick.jones2@...com>
Cc:	<cl@...ux-foundation.org>, <dlstevens@...ibm.com>,
	<netdev@...r.kernel.org>, <netdev-owner@...r.kernel.org>
Subject: RE: IPV4: Enable IP_ID sequencing for all traffic (inquiring mindswant to know why its set to zero)

 >-----Original Message-----
>From: David Miller [mailto:davem@...emloft.net] 
>Sent: Wednesday, July 16, 2008 2:01 PM
>To: rick.jones2@...com
>Cc: cl@...ux-foundation.org; dlstevens@...ibm.com; 
>netdev@...r.kernel.org; netdev-owner@...r.kernel.org
>Subject: Re: IPV4: Enable IP_ID sequencing for all traffic 
>(inquiring mindswant to know why its set to zero)
>
>From: Rick Jones <rick.jones2@...com>
>Date: Wed, 16 Jul 2008 13:39:37 -0700
>
>> I have vague recollections of wanting to avoid (then) locks on the 
>> increment in the non-fragmented paths, assertions that 
>covering cases 
>> like intermediate devices ignoring DF and fragmenting anyway didn't 
>> warrant concern etc.
>
>Partially, yes.
>
>If you look, we do increment the ID for TCP connections which will
>be setting IP_DF, but we allocate such IDs in a socket-local manner
>which keeps these allocations from depleating the real ID cache
>for that destination.
>
>This is legal because when IP_DF is set, the IDs serve no purpose.

The other implied use for IP_ID is as a uniquifier for
duplicate packet detection (DPD), e.g., to detect routing
loops in the network. But, 16 bits doesn't give sufficient
uniqueness for today's data rates anway, so flooding-based
protocols like Simplified Multicast Forwarding (SMF) really
can't use IP_ID by itself for that purpose.

SEAL extends the IP_ID to 32 bits. With 32 bits, it makes
sense to set it as monotonically-incrementing for every
packet out since a network-based DPD mechanism could
potentially make use of it. Also, 32 bits avoids the ID
wraparound issue such that a segmentation and reassembly
mechanism can be used even at high data rates.

SEAL is specified in 'draft-templin-seal', and is also
implemented at:

  http://osprey67.com/seal

This is linux kernel code, but it is not yet ready to be
submitted to netdev. It would be good to get some extra
eyes on the code to get some independent verification
testing and to weed out any bugs. If anyone is interested
in checking it out, please let me know.

Thanks - Fred
fred.l.templin@...ing.com 

>We had to do this because TCP header compression, used by SLIP et
>al., depends upon the ID value incrementing.
>
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@...r.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html