I am having an app in Delphi that monitors UDP traffic. What is the proper way to detect when a QUIC protocol is used? I have the data in a TBytes buffer.
QUIC rfc: https://datatracker.ietf.org/doc/html/rfc9000
Depending on how much of a positive match you're looking for, the effort varies between "walk in the park" and "a bit of a nightmare".
QUIC has a complex handshake, during which the encryption keys are derived, and then it moves into the fully-encrypted, application data phase. On top of this, the protocol is also designed to allow migration of endpoints during the exchange (such as a mobile device jumping between wifi and mobile data), so simply tracking IP addresses and ports isn't going to catch everything.
If all you want is basic detection of QUIC connections being initiated, then all you need to do is to look for the initial packets, which have a clear format, and are only obfuscated (not encrypted).
From RFC9000:
17.2.2. Initial Packet
An Initial packet uses long headers with a type value of 0x00. It
carries the first CRYPTO frames sent by the client and server to
perform key exchange, and it carries ACK frames in either direction.
Initial Packet {
Header Form (1) = 1,
Fixed Bit (1) = 1,
Long Packet Type (2) = 0,
Reserved Bits (2),
Packet Number Length (2),
Version (32),
Destination Connection ID Length (8),
Destination Connection ID (0..160),
Source Connection ID Length (8),
Source Connection ID (0..160),
Token Length (i),
Token (..),
Length (i),
Packet Number (8..32),
Packet Payload (8..),
}
So a quick and dirty way of detecting a QUIC version 1 initial packet, is to check for the following (psuedocode):
( packet[ 0 ] & 0xf0 ) == 0xc0
packet[ 1 ] == 0x00
packet[ 2 ] == 0x00
packet[ 3 ] == 0x00
packet[ 4 ] == 0x01
If you want to go beyond this, it quickly gets exponentially more complicated.
I'd strongly recommend downloading and running wireshark and seeing for yourself what it looks like on the wire.
Related
I've known about SCTP for a decade or so, and although I never got to use it yet, I've always wanted to, because of some of its promising (purported) features:
multi-homing
multiplexing w/o head-of-line blocking
mixed order/unordered delivery on the same connection (aka association)
no TIME_WAIT
no SYN flooding
A Comparison between QUIC and SCTP however claims
SCTP intended to get rid of HOL-Blocking by substreams, but its
Transmission Sequence Number (TSN) couples together the transmission
of all data chunks. [...] As a result, in SCTP if a packet is lost,
all the packets with TSN after this lost packet cannot be received
until it is retransmitted.
That statement surprised me because:
removing head-of-line blocking is a stated goal of SCTP
SCTP does have a per-stream sequence number, see below quote from RFC 4960, which should allow processing per stream, regardless of the association-global TSN
SCTP has been in use in the telecommunications sector for perhaps close to 2 decades, so how could this have been missed?
Internally, SCTP assigns a Stream Sequence Number to each message
passed to it by the SCTP user. On the receiving side, SCTP ensures
that messages are delivered to the SCTP user in sequence within a
given stream. However, while one stream may be blocked waiting for
the next in-sequence user message, delivery from other streams may
proceed.
Also, there is a paper Head-of-line Blocking in TCP and SCTP: Analysis and Measurements that actually measures round-trip time of a multiplexed echo service in the face of package loss and concludes:
Our results reveal that [..] a small number of SCTP streams or SCTP unordered mode can avoid this head-of-line blocking. The alternative solution of multiple TCP connections performs worse in most cases.
The answer is not very scholarly, but at least according to the specification in RFC 4960, SCTP seems capable of circumventing head-of-line blocking. The relevant claim seems to be in Section 7.1.
Note: TCP guarantees in-sequence delivery of data to its upper-layer protocol within a single TCP session. This means that when TCP notices a gap in the received sequence number, it waits until the gap is filled before delivering the data that was received with sequence numbers higher than that of the missing data. On the other hand, SCTP can deliver data to its upper-layer protocol even if there is a gap in TSN if the Stream Sequence Numbers are in sequence for a particular stream (i.e., the missing DATA chunks are for a different stream) or if unordered delivery is indicated. Although this does not affect cwnd, it might affect rwnd calculation.
A dilemma is what does "are in sequence for a particular stream" entail? There is some stipulation about delaying delivery to the upper layer until packages are reordered (see Section 6.6, below), but reordering doesn't seem to be conditioned by filling the gaps at the level of the association. Also note the mention in Section 6.2 on the complex distinction between ACK and delivery to the ULP (Upper Layer Protocol).
Whether other stipulations of the RFC indirectly result in the occurence of HOL, and whether it is effective in real-life implementations and situations - these questions warrant further investigation.
Below are some of the excerpts which I've come across in the RFC and which may be relevant.
RFC 4960, Section 6.2 Acknowledgement on Reception of DATA Chunks
When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted.
Under certain circumstances, the data receiver may need to drop DATA chunks that it has received but hasn't released from its receive buffers (i.e., delivered to the ULP). These DATA chunks may have been acked in Gap Ack Blocks. For example, the data receiver may be holding data in its receive buffers while reassembling a fragmented user message from its peer when it runs out of receive buffer space. It may drop these DATA chunks even though it has acknowledged them in Gap Ack Blocks. If a data receiver drops DATA chunks, it MUST NOT include them in Gap Ack Blocks in subsequent SACKs until they are received again via retransmission. In addition, the endpoint should take into account the dropped data when calculating its a_rwnd.
Circumstances which highlight how senders may receive acknowledgement for chunks which are ultimately not delivered to the ULP (Upper Layer Protocol).Note this applies to chunks with TSN higher than the Cumulative TSN (i.e. from Gap Ack Blocks). This together with unreliability of SACK order represent good reasons for the stipulation in Section 7.1 (see below).
RFC 4960, Section 6.6 Ordered and Unordered Delivery
Within a stream, an endpoint MUST deliver DATA chunks received with the U flag set to 0 to the upper layer according to the order of their Stream Sequence Number. If DATA chunks arrive out of order of their Stream Sequence Number, the endpoint MUST hold the received DATA chunks from delivery to the ULP until they are reordered.
This is the only stipulation on ordered delivery within a stream in this section; seemingly, reordering does not depend on filling the gaps in ACK-ed chunks.
RFC 4960, Section 7.1 SCTP Differences from TCP Congestion Control
Gap Ack Blocks in the SCTP SACK carry the same semantic meaning as the TCP SACK. TCP considers the information carried in the SACK as advisory information only. SCTP considers the information carried in the Gap Ack Blocks in the SACK chunk as advisory. In SCTP, any DATA chunk that has been acknowledged by SACK, including DATA that arrived at the receiving end out of order, is not considered fully delivered until the Cumulative TSN Ack Point passes the TSN of the DATA chunk (i.e., the DATA chunk has been acknowledged by the Cumulative TSN Ack field in the SACK).
This is stated from the perspective of the sending endpoint, and is accurate for the reason emphasized in section 6.6 above.
Note: TCP guarantees in-sequence delivery of data to its upper-layer protocol within a single TCP session. This means that when TCP notices a gap in the received sequence number, it waits until the gap is filled before delivering the data that was received with sequence numbers higher than that of the missing data. On the other hand, SCTP can deliver data to its upper-layer protocol even if there is a gap in TSN if the Stream Sequence Numbers are in sequence for a particular stream (i.e., the missing DATA chunks are for a different stream) or if unordered delivery is indicated. Although this does not affect cwnd, it might affect rwnd calculation.
This seems to be the core answer to what interests you.
In support of this argument, the format of the SCTP SACK chunk as exposed here and here.
Like the wireshark outputs, I captured two TCP packets, one with sequence num 149483 and ack 149453, one with sequence num 149491 and ack 146685.
I think the packet with seq num 149483 is sent first(because it has low sequence num), acked 149453.
Then sent seq num 149491, but here why this packet acked 146685 which already confirmed by the first packets?
Both sequence and acknowledgement numbers are sequence numbers, from the perspective of TCP, but you must remember that each side selects a random initial sequence number from the 32-bit space. In other words, there is no relationship between the sequence and acknowledgement numbers.
The way it works as that hosts A and B establish a connection. Host A will select a random ISN and send that to B in the initial SYN. Host B will acknowledge that number (plus 1, by RFC) and select its own random ISN. Host A will acknowledge that (plus 1, again). From here on out, the sequence numbers are used in connection with the total amount of data sent in a segment to reassemble the segments according to the sequence numbers, with the sequence numbers effectively being used to track the number of bytes sent in each direction in the TCP connection.
Since this is how it works, it is perfectly fine to have a "low" acknowledgement number with a "high" sequence number. It's also fine to have pretty much any other combination that you can imagine.
How can I handle buffer overflow in ndis driver. Can anybody tell some buffer overflow scenarios or some use cases of buffer overflow conditions.
For NDIS miniport drivers
If you receive a packet that is larger than the MTU, discard it. Do not indicate the packet up to NDIS (i.e., do not pass the packet to NdisMIndicateReceiveNetBufferLists). If possible, increment the ifInErrors statistical counter.
The above rule is not affected by the NDIS_PACKET_TYPE_PROMISCUOUS flag; do not indicate excessively-large packets even when in promiscuous mode. However, you should indicate excessively-small (aka "runt") packets when in promiscuous mode, if your hardware permits it.
If you are asked to transmit a packet that is larger than the MTU, do not attempt to transmit it. Assign NET_BUFFER_LIST::Status = NDIS_STATUS_INVALID_LENGTH and return the NBL back to NDIS with NdisMSendNetBufferListsComplete. (I wouldn't expect you to ever see such a packet; it would be a bug for NDIS to attempt to send you such a packet.)
For NDIS protocol drivers
If you receive a packet that is larger than the MTU, you are free to discard it.
Never attempt to send a packet that is larger than the MTU.
For NDIS filter drivers
If a filter receives a packet that is larger than the MTU (FilterReceiveNetBufferLists), the filter may immediately discard the packet (NdisFReturnNetBufferLists if the receive indication is not made with NDIS_RECEIVE_FLAGS_RESOURCES, or just returning immediately if the resources flag is set).
If a filter is asked to send a packet that is larger than the MTU (FilterSendNetBufferLists), the filter may assign NET_BUFFER_LIST::Status = NDIS_STATUS_INVALID_LENGTH and return the packet immediately (NdisFSendNetBufferListsComplete).
Filters are not obligated to validate the size of every packet that passes through them. However, your filter should validate the size of any packets where a malformed packet would otherwise cause your filter to trigger a buffer overflow. For example, if your filter copies all ARP replies into a pre-allocated buffer, first validate that the ARP reply isn't too large to fit into the buffer. (This is not strictly necessary, since the miniport "shouldn't" give you an excessively-large packet. However, you are on the network datapath, which means you're handling untrusted data being processed by a potentially-buggy miniport. A little extra defense-in-depth is a good idea.)
Filters must not originate packets that are larger than the MTU (on either the send or receive paths).
I want to write a receiver program using raw socket
it will use recvfrom() to receive packets
so I want to check the IP header and tcp header of a packet
when a program sends a packet, it will pay attention to the network byte order and host byte order problem
but for my recever program, when I use recvfrom(sockfd,mesg,1000,0,(struct sockaddr *)&cliaddr,&len);
what is the byte order of the data in the packets? it is network byte order or host byte order?
and how to deal with it?
for this example
http://www.binarytides.com/packet-sniffer-code-in-c-using-linux-sockets-bsd/
the author doesn't take into account the byte order problem when dealing with the received packets, why?
thanks!
what is the byte order of the data in the packets?
The convention is that network order is big endian order. However, the data you receive is the data you sent: nobody magically modifies "integers" to change their endianness.
and how to deal with it?
Use ntohl and ntohs when interpreting integer data
Be aware that bitfield endianness isn't standard
the author doesn't take into account the byte order problem when
dealing with the received packets,
The link you posted shows ntohs and ntohl calls. The author does handle endianness at least to some extent.
I need to calculate total data transfer while transferring a fixed size data from client to server in TCP/IP. It includes connecting to the server, sending request,header, receiving response, receiving data etc.
More precisely, how to get total data transfer while using POST and GET method?
Is there any formula for that? Even a theoretical one will do fine (not considering packet loss or connection retries etc)
FYI I tried RFC2616 and RFC1180. But those are going over my head.
Any suggestion?
Thanks in advance.
You can't know the total transfer size in advance, even ignoring retransmits. There are several things that will stop you:
TCP options are negotiated between the hosts when the connection is established. Some options (e.g., timestamp) add additional data to the TCP header
"total data transfer size" is not clear. Ethernet, for example, adds quite a few more bits on top of whatever IP used. 802.11 (wireless) will add even more. So do HDLC or PPP going over a T1. Don't even think about frame relay. Some links may use compression (which will reduce the total size). The total size depends on where you measure it, even for a single packet.
Assuming you're just interested in the total octet size at layer 2, and you know the TCP options that will be negotiated in advance, you still can't know the path MTU. Which may change, even while the connection is in progress. Or if you're not doing path MTU discovery (which would be wierd), then the packet may get fragmented somewhere, and the remote end will see a different amount of data transfer than you.
I'm not sure why you need to know this, but I suggest that:
If you just want an estimate, watch a typical connection in Wireshark. Calculate the percent overhead (vs. the size of data you gave to TCP, and received from TCP). Use that number to estimate: it will be close enough, except in pathological situations.
If you need to know for sure how much data your end saw transmitted and received, use libpcap to capture the packet stream and check.
i'd say on average that request and response have about 8 lines of headers each and about 30 chars per line. Then allow for the size increase of converting any uploaded binary to Base64.
You didn't say if you also want to count TCP packet headers, in which case you could assume an MTU of about 1500 so add 16 bytes (tcp header) per 1500 data bytes
Finally, you could always setup a packet sniffer and count actual bytes for a sample of data.
oh yeah, and you may need to allow for deflate/gzip encoding as well.