Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:




basics logo Security Basics mailing list archives

RE: TCP/IP CRC question
From: "Ted A" <arcturous () hotmail com>
Date: Thu, 07 Oct 2004 16:42:54 +0000

Also, remember that the stack was built with the intention of being completely modular. By allowing each layer to be responsible for it's own duties, you don't have a common point of failure; IE: Bad checksum as a result of routing will also mean bad data even if the data is good. By having the seperate points of responsibility, troubleshooting is more reliable.




&gt; -----Original Message-----
&gt; From: Jorge Mendez Bonini [mailto:jlmb () cableonda net]
&gt; Sent: Tuesday, October 05, 2004 11:15 PM
&gt; To: security-basics () securityfocus com
&gt; Subject: TCP/IP CRC question
&gt;
&gt;
&gt; I've been reading about the TCP/IP protocol stack
&gt; (TCP/Ilustrated Vol1
&gt; by Richard Stevens) lately and since Ethernet is quite common
&gt; nowadays
&gt; almost all link layer examples refer to it (I also checked
&gt; Douglas Comer
&gt;   Internetworking with TCP/IP vol1).
&gt; I tried searching RFC but found it very time consuming without good
&gt; results (maybe I'm not used to it...yet)
&gt;
&gt; The Ethernet Frame contains a field known as FCS which contains a CRC.
&gt; Now, my question is:
&gt; If the CRC is generated from DATA field among others, What's
&gt; the point
&gt; of using checksums on the upper protocolos (IP checksums etc..)?
&gt;
&gt; Thanks for your time.
&gt;



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]