Is it possible that tcp header patterns to behave differently from rfc specification in normal case(i mean when it is not any intrusion or anomaly)? or it will always follow rfc standard in all cases where there is no attack?
The RFC is there to be followed. A host that does not conform to the RFCs (a) cannot be connected directly to the Internet and (b) won't work correctly.
Related
While taking a look at the rfc for socks version 5 I was wondering whether there are prior versions to socks5. And there was SOCKS4 but I was not able to find a RFC for SOCKS4 instead I found this document
https://www.openssh.com/txt/socks4.protocol
Which gave the implmentation details of SOCKS4. My question is that is there a RFC seperately for SOCKS4 if not why?
I'm new to networks and it would be great to know the answer for this question.
I want to know whether there is an RFC for SOCKS4
Im just looking for the RFC of BitTorrent Protocol.
I reached to the document here is it but what is actually I want is the number of the RFC
You can actually google that.
https://www.rfc-editor.org/rfc/rfc5694
As I understand, TCP has a relatively reliable checksum mechanism, but there is a very small yet present chance of it returning a false positive.
Does HTTP use an application level checksum (perhaps a hash)? If not, why?
Yup (: the specs for HTTP/1.1 (RFC 2616) allow the use of a Content-MD5 header. Take a look at its section 14.15.
Copy-pasted:
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
an MD5 digest of the entity-body for the purpose of providing an
end-to-end message integrity check (MIC) of the entity-body.
What are the mechanisms/approaches to validate the UDP payload in case of SIP? SIP message doesn't contain size of header or the body, so how to verify that the payload is valid? In contrast, RTP indicates the size, so given the length value from UDP header it is possible to check RTP for validit and integrity. Can something similar be done for SIP?
Mark.
Your question has two parts:
How do I validate SIP headers? The only way to validate SIP headers is to parse them according to the rules of section 7.3.1 of RFC 3261. There are SIP parsers available for many different languages.
How do I validate the body of SIP messages? There is a mechanism built into SIP: the Content-Length header specifies the size of the body. In the general case, the body can contain an arbitrary MIME type, and no further validation rules apply.
Edit: Per Frank Shearar's comment below, Content-Length is not required for SIP messages conveyed via UDP. But if your UA supports it, you can take advantage of it.
I need to programmatically determine the Router NAT type in my program. I did look at some of the STUN related answers and UPnP related information on SO. But did not get any definitive answers.
I looked at STUN RFC (rfc 5389) and it does not specify how to determine the NAT type. It does mention that it's previous version (RFC 3489) did provide the mechanism to determine NAT type. But also mentions that
Furthermore. classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Given above, could you please advice on how I should go ahead with determination of router NAT type in my software. Further, now that RFC 3489 is obsoleted is there any other means?
Thanks in advance.
RFC 3489 was split into three different RFCs:
RFC 5389 - basic STUN protocol. Basic protocol of STUN binding request and binding response are largely the same as RFC 3489. The protocol header gets updated with a magic cookie occupying some of the transaction id field. Some STUN attributes get redefined. A few new ones added (specifically - XOR_MAPPED_ADDRESS). Some changes to how STUN auth is done. NAT behavior and classification discussion moved to RFC 5780.
RFC 5780 - "Nat Behavior discovery using STUN". The basic change to NAT type discovery was to distinguish NAT port mapping behavior separate from NAT filtering behavior. Whereas RFC 3489 would try to classify a NAT into one of several buckets ("cone", "port restricted", "symmetric") - which was just too generic to describe a NAT.
RFC 5769 - Just outlines what the hex dump of a few different STUN message types would look like.
Out of curiosity, I suppose knowing if your app is running behind a NAT is useful. But how would knowing the NAT's behavior influence your code path?
Shameless plug - Use my STUN Server code that is hosted on GitHub.