Ok ,
Question 1
SSL/TLS or any other security protocal I have seen must run above the transport/ip layers or else if you encrypted the TCP/IP or any other protocal layer under the application layer the transmission won't work
since all the computers would need to know how to decrypt the header info to send the packet to the next hop ,..etc
SSL/TLS encrypt only the application/presentation/session layer protocal packets like HTTP , FTP , SMTP , DHCP,DNS...etc (really this is the only data the user or application would be worried about a third party seeing anyway)
However I came across IPsec that say's it encrypts at the ip protocal level.
So I am wondering how these encrypted packets can be sent if the header info is encrypted at that level? This must only beable to be used in special networks that are using something different then UDP , TCP ....etc to send the data.
My problems with all this is I would believe you have to only have security at the application level or else how would the network know which computer ip to send , which port ,...etc (you at least need the TCP or UDP layer header to be unencrypted )
Question 2
The format of the ip header is very easy to understand.
the protocal field in the ip header specifies the layer up protocal or an alternative ip level protocal for example like
17 = UDP , 6=TCP , 1=ICMP , 2=IGMP ,89=OSPF ,132=SCTP ,...etc to name a few (basically their is tons of different possiblities but usually only UDP ,TCP , and a few others are ever used at the ip or tcp layer levels)
So if you where to write an OS with network support you would have to write a TCP/IP , UDP/IP protocal handler...
general procedure
1)Skiping over the ethernet packet by reading the packet size info in the ethernet packet (but before you do check to see what the next layer packet is in the ethernet header (i.e weather it is arp , ipv4 , ipv6,..etc)
2) assuming it is ipv4 get the data for the destination ip check the protocal field for the next level protocal (assuming it is TCP = 6 )
3) move to the TCP packet and get the port info ,...etc
4) extract the TCP packet data and hand it over to the application layer service that is running on that port after you have reasemblied all of the TCP data packets
I am overly simplifying the procedure and leaving out syn/ack window ,checksum ..etc fields that must be checked and maintained/pieced together....
Getting to the question
If your ip protocal is something like ICMP the tcp handler would get the packet but it doesn't get any port info when the recieving computer recieves it? So how can it send the sender an ICMP which port does it use?
Or does the general OS tcp handlers just check to see if it is an ICMP packet (if it is then it reads the source ip and sends an ICMP ack packet based on that)
If the latter is the case then any transmitted packed that didn't at least get to the transport layer level to specify a port before being transmitted by the nic would just be used for pinging , and other things not for data transfering...
Because I would think you need a port and a service running on it to be a useful data transfer protocal...
That is why c , java ,...etc network api implement sockets in 2 flavors
UDP connectionless, TCP connection.
And normal api don't allow you to muck with lower then TCP /UDP packets ( unless you use raw sockets , winpcap api ,...etc) The thing is socket at the UDP or TCP level provided 99% of any type of transmission protocal need to a programmer (the 1% is ICMP , ...etc packets that you need a special API for)
In general though to cook up a DNS , SMTP , DHCP ,FTP ,..or any other network packet that a user/programmer would ever use can be accomplished useing regular TCP or UDP sockets.
Other then some data link layer protocals , like arp , rarp ,...etc which a normal network socket cann't manipulate unless jpcap or winpcap api's are used or win32 network device driver programs are made to hook into this low level
( this level is really only used to get physical address to ip address translation visa-versa)
every transmission network I have worked on use TCP/IP or UDP/IP
Is their any other used network schemes used for transmitting data between 2 computers over a network using something different the UDP/IP or TCP/IP... ( I know their is old stuff like apple talk ,...etc but currently I am wondering if their is any in use currently)
netbios is an application layer protocal and as such runs on either TCP or UDP
smtp uses TCP
http uses TCP
this is all application , presentation , session level
...everything useful must use these?
I am looking for something different at the TCP or IP levels. I don't really think their is and their really shouldn't have to be.
Thanks
Question 1
SSL/TLS or any other security protocal I have seen must run above the transport/ip layers or else if you encrypted the TCP/IP or any other protocal layer under the application layer the transmission won't work
since all the computers would need to know how to decrypt the header info to send the packet to the next hop ,..etc
SSL/TLS encrypt only the application/presentation/session layer protocal packets like HTTP , FTP , SMTP , DHCP,DNS...etc (really this is the only data the user or application would be worried about a third party seeing anyway)
However I came across IPsec that say's it encrypts at the ip protocal level.
So I am wondering how these encrypted packets can be sent if the header info is encrypted at that level? This must only beable to be used in special networks that are using something different then UDP , TCP ....etc to send the data.
My problems with all this is I would believe you have to only have security at the application level or else how would the network know which computer ip to send , which port ,...etc (you at least need the TCP or UDP layer header to be unencrypted )
Question 2
The format of the ip header is very easy to understand.
the protocal field in the ip header specifies the layer up protocal or an alternative ip level protocal for example like
17 = UDP , 6=TCP , 1=ICMP , 2=IGMP ,89=OSPF ,132=SCTP ,...etc to name a few (basically their is tons of different possiblities but usually only UDP ,TCP , and a few others are ever used at the ip or tcp layer levels)
So if you where to write an OS with network support you would have to write a TCP/IP , UDP/IP protocal handler...
general procedure
1)Skiping over the ethernet packet by reading the packet size info in the ethernet packet (but before you do check to see what the next layer packet is in the ethernet header (i.e weather it is arp , ipv4 , ipv6,..etc)
2) assuming it is ipv4 get the data for the destination ip check the protocal field for the next level protocal (assuming it is TCP = 6 )
3) move to the TCP packet and get the port info ,...etc
4) extract the TCP packet data and hand it over to the application layer service that is running on that port after you have reasemblied all of the TCP data packets
I am overly simplifying the procedure and leaving out syn/ack window ,checksum ..etc fields that must be checked and maintained/pieced together....
Getting to the question
If your ip protocal is something like ICMP the tcp handler would get the packet but it doesn't get any port info when the recieving computer recieves it? So how can it send the sender an ICMP which port does it use?
Or does the general OS tcp handlers just check to see if it is an ICMP packet (if it is then it reads the source ip and sends an ICMP ack packet based on that)
If the latter is the case then any transmitted packed that didn't at least get to the transport layer level to specify a port before being transmitted by the nic would just be used for pinging , and other things not for data transfering...
Because I would think you need a port and a service running on it to be a useful data transfer protocal...
That is why c , java ,...etc network api implement sockets in 2 flavors
UDP connectionless, TCP connection.
And normal api don't allow you to muck with lower then TCP /UDP packets ( unless you use raw sockets , winpcap api ,...etc) The thing is socket at the UDP or TCP level provided 99% of any type of transmission protocal need to a programmer (the 1% is ICMP , ...etc packets that you need a special API for)
In general though to cook up a DNS , SMTP , DHCP ,FTP ,..or any other network packet that a user/programmer would ever use can be accomplished useing regular TCP or UDP sockets.
Other then some data link layer protocals , like arp , rarp ,...etc which a normal network socket cann't manipulate unless jpcap or winpcap api's are used or win32 network device driver programs are made to hook into this low level
( this level is really only used to get physical address to ip address translation visa-versa)
every transmission network I have worked on use TCP/IP or UDP/IP
Is their any other used network schemes used for transmitting data between 2 computers over a network using something different the UDP/IP or TCP/IP... ( I know their is old stuff like apple talk ,...etc but currently I am wondering if their is any in use currently)
netbios is an application layer protocal and as such runs on either TCP or UDP
smtp uses TCP
http uses TCP
this is all application , presentation , session level
...everything useful must use these?
I am looking for something different at the TCP or IP levels. I don't really think their is and their really shouldn't have to be.
Thanks
Last edited: