| 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: <CADvbK_cmR4eS_SStfaT5fOBc0KSdXUW=QaFWcg8xK3jvZQoKAQ@mail.gmail.com>
Date: Tue, 21 Feb 2017 23:53:54 +0800
From: Xin Long <lucien.xin@...il.com>
To: Sun Paul <paulrbk@...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
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