| 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
| ||
|
Message-ID: <CAFXGft+f8AsMQe-MtkKoaCmGazbBR09nP6SiOj9__k13c-23YQ@mail.gmail.com>
Date: Wed, 22 Feb 2017 10:29:50 +0800
From: Sun Paul <paulrbk@...il.com>
To: Xin Long <lucien.xin@...il.com>
Cc: Michael Tuexen <Michael.Tuexen@...chi.franken.de>,
David Laight <David.Laight@...lab.com>,
Neil Horman <nhorman@...driver.com>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Problem on SCTP
Hi Xin
do you mean we need to patch the kernel?
On Wed, Feb 22, 2017 at 10:00 AM, Xin Long <lucien.xin@...il.com> wrote:
> On Wed, Feb 22, 2017 at 9:12 AM, Sun Paul <paulrbk@...il.com> wrote:
>> Hi
>>
>> the router is actually is a linux running on RHEL6.8
>> (2.6.32-642.4.2.el6.x86_64). it uses iptables to do SNAT aand DNAT
>> forward.
> https://bugzilla.redhat.com/show_bug.cgi?id=1412038
>
> sctp_manip_pkt->sctp_compute_cksum:
> struct sctphdr *sh = sctp_hdr(sub);
>
> But in rhel6, skb->transport_header is not yet set at that time.
> This patch should be backported into rhel6.
>
> commit 21d1196a35f5686c4323e42a62fdb4b23b0ab4a3
> Author: Eric Dumazet <edumazet@...gle.com>
> Date: Mon Jul 15 20:03:19 2013 -0700
>
> ipv4: set transport header earlier
>
>
>>
>> On Tue, Feb 21, 2017 at 11:53 PM, Xin Long <lucien.xin@...il.com> wrote:
>>> On Tue, Feb 21, 2017 at 12:26 PM, Sun Paul <paulrbk@...il.com> wrote:
>>>> Hi,
>>>>
>>>> sorry to get back late, the platform is running on KVM. and this
>>>> problem is resolved by moving to VMware environment, however, a new
>>>> problem is coming out, we noticed that the HB REQ is being ABORT from
>>>> client.
>>>>
>>>>
>>>> 03:32:35.233572 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1)
>>>> [HB REQ] (from server to sctp router)
>>>> 03:32:35.233603 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1)
>>>> [HB REQ] (from sctp router to client)
>>>> 03:32:35.233852 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1)
>>>> [ABORT] (from client to sctp router)
>>>>
>>>> 03:32:37.928679 IP 10.165.250.22.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>> 03:32:37.928717 IP 192.168.2.14.3868 > 192.168.2.13.40001: sctp (1) [HB REQ]
>>>> 03:32:37.929247 IP 192.168.2.13.40001 > 192.168.2.14.3868: sctp (1) [ABORT]
>>>>
>>>> For the above packet flow, 10.165.250.22 is the server and
>>>> 192.168.2.13 is the client, the server 10.165.250.22 sends HB REQ to
>>>> client 192.168.2.13 through 192.168.2.14 (the SCTP router), and the
>>>> SCTP router change the src address before forward the HB REQ to the
>>>> client.
>>>>
>>>> But somehow the client is ABORT the HB REQ, any idea? is it related to
>>>> the HEARTBEAT information? or the checksum again>?
>>> The incorrect checksum won't cause ABORT, but the abnormal HB REQ
>>> could be, if HB information was modified when calculating the checksum
>>> on router, the ABORT may be caused in client process.
>>>
>>> is your SCTP router linux ? if yes, what's the kernel version ?
>>>
>>>>
>>>> On Fri, Jan 13, 2017 at 9:19 PM, Michael Tuexen
>>>> <Michael.Tuexen@...chi.franken.de> wrote:
>>>>>> On 13 Jan 2017, at 10:43, Michael Tuexen <Michael.Tuexen@...chi.franken.de> wrote:
>>>>>>
>>>>>> Your router does NOT change any field in the SCTP packet, but the
>>>>>> SCTP checksum was modified from
>>>>>> Checksum: 0xbaea49e5 (not verified)
>>>>>> to
>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>> At least one of these is wrong. Read the tracefiles in wireshark and
>>>>>> enable checksum validation and wireshark will tell you which one is
>>>>>> correct. (That is why I asked for .pcap file instead of a .txt).
>>>>>>
>>>>>> My guess is that the initial checksum is correct and your box middlebox
>>>>>> not only changes the destination address and ttl field and header
>>>>>> checksum in the IP-header (which is expected) but also incorrectly the
>>>>>> SCTP checksum. Since no field in the SCTP packet has changed, the checksum
>>>>>> must be the same.
>>>>> At the server have a look at the SNMP counters:
>>>>> cat /proc/net/sctp/snmp
>>>>> You should find a line staring with
>>>>> SctpChecksumErrors
>>>>> If the number reported there is positive, the node received packets
>>>>> with checksum errors.
>>>>>
>>>>> Best regards
>>>>> Michael
>>>>>>
>>>>>> Best regards
>>>>>> Michael
>>>>>>> On 13 Jan 2017, at 04:29, Sun Paul <paulrbk@...il.com> wrote:
>>>>>>>
>>>>>>> Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
>>>>>>> Encapsulation type: Ethernet (1)
>>>>>>> Arrival Time: Jan 6, 2017 16:52:49.662321000 Malay Peninsula Standard Time
>>>>>>> [Time shift for this packet: 0.000000000 seconds]
>>>>>>> Epoch Time: 1483692769.662321000 seconds
>>>>>>> [Time delta from previous captured frame: 0.000179000 seconds]
>>>>>>> [Time delta from previous displayed frame: 0.000179000 seconds]
>>>>>>> [Time since reference or first frame: 0.000179000 seconds]
>>>>>>> Frame Number: 2
>>>>>>> Frame Length: 98 bytes (784 bits)
>>>>>>> Capture Length: 98 bytes (784 bits)
>>>>>>> [Frame is marked: False]
>>>>>>> [Frame is ignored: False]
>>>>>>> [Protocols in frame: eth:ethertype:ip:sctp]
>>>>>>> Ethernet II, Src: Vmware_81:41:6b (00:50:56:81:41:6b), Dst:
>>>>>>> Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> Destination: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> Address: Vmware_81:a6:a3 (00:50:56:81:a6:a3)
>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>> address (factory default)
>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>> Source: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>> Address: Vmware_81:41:6b (00:50:56:81:41:6b)
>>>>>>> .... ..0. .... .... .... .... = LG bit: Globally unique
>>>>>>> address (factory default)
>>>>>>> .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>>>>>>> Type: IPv4 (0x0800)
>>>>>>> Internet Protocol Version 4, Src: 192.168.206.83, Dst: 192.168.206.66
>>>>>>> 0100 .... = Version: 4
>>>>>>> .... 0101 = Header Length: 20 bytes (5)
>>>>>>> Differentiated Services Field: 0x02 (DSCP: CS0, ECN: ECT(0))
>>>>>>> 0000 00.. = Differentiated Services Codepoint: Default (0)
>>>>>>> .... ..10 = Explicit Congestion Notification: ECN-Capable
>>>>>>> Transport codepoint '10' (2)
>>>>>>> Total Length: 84
>>>>>>> Identification: 0x0000 (0)
>>>>>>> Flags: 0x02 (Don't Fragment)
>>>>>>> 0... .... = Reserved bit: Not set
>>>>>>> .1.. .... = Don't fragment: Set
>>>>>>> ..0. .... = More fragments: Not set
>>>>>>> Fragment offset: 0
>>>>>>> Time to live: 63
>>>>>>> Protocol: SCTP (132)
>>>>>>> Header checksum: 0x1d3d [validation disabled]
>>>>>>> [Good: False]
>>>>>>> [Bad: False]
>>>>>>> Source: 192.168.206.83
>>>>>>> Destination: 192.168.206.66
>>>>>>> [Source GeoIP: Unknown]
>>>>>>> [Destination GeoIP: Unknown]
>>>>>>> Stream Control Transmission Protocol, Src Port: 50001 (50001), Dst
>>>>>>> Port: 3868 (3868)
>>>>>>> Source port: 50001
>>>>>>> Destination port: 3868
>>>>>>> Verification tag: 0x00000000
>>>>>>> [Assocation index: 0]
>>>>>>> Checksum: 0xa9a86d3f (not verified)
>>>>>>>
>>>>>>> INIT chunk (Outbound streams: 3000, inbound streams: 3000)
>>>>>>> Chunk type: INIT (1)
>>>>>>> 0... .... = Bit: Stop processing of the packet
>>>>>>> .0.. .... = Bit: Do not report
>>>>>>> Chunk flags: 0x00
>>>>>>> Chunk length: 52
>>>>>>> Initiate tag: 0xe79f40cb
>>>>>>> Advertised receiver window credit (a_rwnd): 62464
>>>>>>> Number of outbound streams: 3000
>>>>>>> Number of inbound streams: 3000
>>>>>>> Initial TSN: 176990880
>>>>>>> IPv4 address parameter (Address: 192.168.206.83)
>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> IP Version 4 address: 192.168.206.83
>>>>>>> IPv4 address parameter (Address: 192.168.1.83)
>>>>>>> Parameter type: IPv4 address (0x0005)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> IP Version 4 address: 192.168.1.83
>>>>>>> Supported address types parameter (Supported types: IPv6, IPv4)
>>>>>>> Parameter type: Supported address types (0x000c)
>>>>>>> 0... .... .... .... = Bit: Stop processing of chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 8
>>>>>>> Supported address type: IPv6 address (6)
>>>>>>> Supported address type: IPv4 address (5)
>>>>>>> ECN parameter
>>>>>>> Parameter type: ECN (0x8000)
>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>> processing of the chunk
>>>>>>> .0.. .... .... .... = Bit: Do not report
>>>>>>> Parameter length: 4
>>>>>>> Forward TSN supported parameter
>>>>>>> Parameter type: Forward TSN supported (0xc000)
>>>>>>> 1... .... .... .... = Bit: Skip parameter and continue
>>>>>>> processing of the chunk
>>>>>>> .1.. .... .... .... = Bit: Do report
>>>>>>> Parameter length: 4
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" 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 linux-sctp" in
>>>> the body of a message to majordomo@...r.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists