low level networking ?

Discussion in 'Computing and Networks' started by Mathematics!, May 12, 2010.

  1. Mathematics!

    Thread Starter Senior Member

    Jul 21, 2008
    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.

    Last edited: May 12, 2010
  2. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    Last edited: May 13, 2010
  3. bertus


    Apr 5, 2008
  4. rjenkins

    AAC Fanatic!

    Nov 6, 2005
    There are various other none-IP protocols.

    The commonest ones may have been Novell Netware's IPX/SPX

    and Microsoft's original NetBIOS

    Another one is the ham radio AX25 Packet Radio system, derived from the X25 protocol used for some of the first telecomms packetized data systems.

    Re. your question 1, one of the typical setups uses software that creates a 'fake' network interface. Any traffic to be encrypted is routed to that interface rather than the real one, and the software layer handles the encryption before sending the data over the real interface.

    In common terminology it's a tunnel interface. The same principle is used transfer IPv6 over networks that can't handle it natively.
  5. braindead

    New Member

    May 12, 2010
    The header is only encrypted in tunneling mode. In transport mode the header is "plaintext". Transport mode allows you to transparently use encryption without upper layers needing to know that the IP-layer is encrypted, hence any application relying on IP can be secured without breaking anything or require upper support.

    In tunneling mode you still pack the packet into a new packet, where the header yet again is unencrypted.
  6. Mathematics!

    Thread Starter Senior Member

    Jul 21, 2008
    I guess I don't understand how tunneling works then.
    How can you encrypt the ip packet/header stuff and still manage to transport the packet?

    If all IPsec and tunnel protocals that work at layers lower then application level encryption do is just wrap the packet into another packet with the same header but unencypted then I don't see much benifit from the application layer encryption ones?

    Basically is IPsec just encrypting the ip packet and then wrapping that inside another ip packet which has an unencrypted ip header.
    Either way if this is it then I just see a waste of space/data being sent... not an improvement in anyway????

    Another question I had is why is their only 0xFFFF = 65535 number of ports in a computer.
    Is this just because of the port size in the TCP /UDP packet being 2 bytes long or is their some physical hardware reason behind this?
    For instance if somebody made a new protocal at the TCP layer which had the port field being 4 bytes in size would he beable to have 4Gigs worth of ports to work with?

    Or is the network ports tied to a physical location on a computer such as the IO port that you use to write device drivers ,...etc etc asm IN , OUT commands

  7. braindead

    New Member

    May 12, 2010
    Transport Mode: You don't encrypt the header, so routing is easy.

    Tunnel Mode: You encrypt header+packet, and then you put the result in another packet. It is thus used as point-2-point and only the receiver will know any true information regarding the encrypted packet. Routing is of course still possible for the tunneled packet.

    It was just some semi-arbitrary choice that seemed reasonable at the time. It has nothing to do with device drivers.
  8. Mathematics!

    Thread Starter Senior Member

    Jul 21, 2008
    But I don't see the point of encrypting the ip header at all what is so privite about that part... plus when transporting it is the identical header unencrypted... (plus their is only source ip , and destination ip stuff in their any way not anything more private then that...)

    Anyway about the max number of network ports...
    So your saying if the header had a bigger field for the port number we could have as many ports as the size of the port field supported....
    Their is no physical hardware reason why we only have 65535 max numbers of ports it is all software related.

    Then I have to ask when a socket is set to listen on a port is the OS TCP/IP protocal handler informed that a socket is listening on a specific port and when the handler receives a packet for that port it reassemblies it and passes it to that socket.

    In any case If you extended the max number of network ports you would have to modify the TCP/IP protocal handler to deal with this different number as well so 65535 probably is not going to change....
    Just was curious if it is possible or had any ties to hardware.
    But seems to me it is all software based.

  9. braindead

    New Member

    May 12, 2010
    If I don't want anyone on the internet to know what the FINAL recipient is, or even how large the message is etc, then using the tunnel mode makes perfect sense. Surely it is routed to the router, but that doesn't necessarily tell you that much. You can implement a totally transparent bridge like this over the internet.

    No, 65535 is not going to change for IPv4, it is what it is. 16-bit probably just seemed enough.

    What do you mean by re-assembling the packet? The packet is what it is.
  10. Mathematics!

    Thread Starter Senior Member

    Jul 21, 2008
    Ya, but if it is routed to the router couldn't somebody do arp poisoning or something to route the packets thru them...
    If that happened then the header would beable to be optained.
    Either way hiddening the source ip and length of packet info doesn't really do much. Because even if you had this info SSL application layer encryption would provided an almost impossible way of reading the user data.

    I just don't get what the point of doing encryption at any lower level the the application layer level is going to provide. Plus I don't see it being to hard to figure out the header stuff based on arp posioning or some other lower layer means (that is if you are on the same local loop )

    I know it is not going to change but I just wanted to know if it was hardware related to the NIC card support or software based.
    Now that I know it was software based in theory if somebody wanted to create a TCP protocal stack/handler for their own homemade OS they could specify a port field that is greater then 2bytes long which could be used to extend the 65535 max amount of ports. ( in theory this max is more then enough)

    network max ports are software maxes not hardware such as the amount of memory , or IO ports,...etc
    That is all I was trying to get at

    As for the reassembly I just meant in the case of packet fragmentation your TCP handler would have to reassembly the complete packet before handing it to the socket....etc

    Other then IPsec and a few other tunneling protocals (like VPN uses)
    These seem to be it at the IP layer. Is their any security schemes that work at encrypting the TCP layer or are their just the few IP layer encryption like IPSec ,...etc and the application layer encryption schemes like SSL TSL , PGP , MD5 ,....etc

    Also is their any encryption schemes for the data layer (lowest programable software level layer)
    I don't think their are and what good would they be it would only be for a next hop or to optain an ip address from a physical address (arp/rarp... )
    Although it would be nice if the router had a built in way to deal with the this to provided away of not letting people arp posion and such.

    I know for the physical layer we have frequency hopping schemes but that is about it and these aren't really software schemes more modulation schemes which change their frequencies based on frequency tables or other algorthims to provide a hard way for 3rd parties to listen in on it. But to break these all you would need is knowledge of the frequency hopping table, timeing intervals ,..etc.

    I am grouping presentation level , session level , application level all into application level encryption
    So their is only TCP level , IP level , Datalink level , PHYSICAL level left.
    So I know their is encryption schemes at IP level like IPsec but is their any at TCP or Datalink?
    Last edited: May 13, 2010
  11. braindead

    New Member

    May 12, 2010
    You have to realize that TCP is for providing a transport service, with flow control, resending, etc. The reason for putting the encryption at the IP level with IPSec is because it can work transparently for any application, evolving such a feature for TCP then doesn't make much sense, since TCP works over IP and there is already IPSec. If you are not happy with IPSec then you are free to do anything in above layers.

    For the data link layer, again, the purpose is to transmit the bits. And at the physical layer your task is to represent the bits. You could certainly mix it all together and secure it here or there or wherever, but why talk about a layered model at all then.

    The layered model is there to make it easier and clearer. On the data link layer you get bits from A to B, in a frame, and perhaps even some addressing.

    Realize what the layering is for, and realize that it is not perfect nor complete. Adding security at IP-level makes sense. Adding security yet again at TCP does not. Adding security at application level makes sense.

    Think about the realities and forget about the models, unless you use them to your favor.
  12. Mathematics!

    Thread Starter Senior Member

    Jul 21, 2008
    Well if you have IPsec then why have security in the application layer level or another words if you have it in the application layer level why do you even want it at any lower level.
    I guess that is what is confusing me what benfit does IPsec have over the SSL ,...application layer security? Apart from being at a lower level.... no real data below the application layer need to be private...
    who really carries if people can see the ip address , ports , packet length ,..etc...

    The best they can do is capture your packets which are meaningless with out being able to decrypt them.
    Unless they are planning a DOS attack , or a session hijacking these all can be dealt with by other means....

    ALSO I STILL DON'T get how something uses IPsec get transmitted to the proper place.
    For example
    computer A wants to send computer B a packet using IPSec how would this be done.
    Say computer A is behind a router A then the internet and computer B is behind a router B then the internet.

    So computer A sends a encrypted IP header how does the router understand where the destination ip is if it is encrypted....???

    The only thing I can see is if every router routeing the packet from computer A to computer B is decrypting the packet then encrypting it again to the next hop ? Else you need the actual unencypted packet headers ?

    I guess I don't understand how this tunnel stuff works.
    Care to eleborate. Maybe that is the problem that I don't see the point or difference in use application layer or ip layer encryption....
  13. rjenkins

    AAC Fanatic!

    Nov 6, 2005
    The key word is 'tunnel'

    An ipsec connection (or any tunneled connection, or a 'VPN') is set up to a fixed endpoint.

    An example would be a business with two sites. Rather than a leased private connection, they have an ipsec tunnel set up to link the two networks.

    The machines as the two sites can then appear to be on the same network; any IP addresses within the company subnet are routed via the tunnel interface.

    All the conventional 'public address' IP routing etc. is done on the encrypted and encapsulated data packets, the private data is never NATed and in effect never passes outside the private network boundary.

    Think of it as the tunnel interfaces forming a 'wormhole' between the two halves of the network.

    A system may have more than one tunnel set up, possibly dozens to different sites and for different uses. Which is used for what traffic is down to the routing configuration.

    ipsec is just one of many tunnel or VPN types.

    More info: http://en.wikipedia.org/wiki/Vpn

    IPSec is the first item in the section on Security Mechanisms
    Last edited: May 14, 2010
  14. braindead

    New Member

    May 12, 2010
    It looks like this, you have a packet (A) which you want to transmit to another person on the internet. Packet A consists of

    (A-header) + (A-payload)
    you encrypt ONLY THE PAYLOAD, and slightly modify the A-header so that you know that the payload is encrypted and add a few other fields to the "payload", you could say, for verification etc. But the actual payload is not visible. So now you have

    (A-header extended) + (A-payload encrypted)
    and that you can send and route over the internet without issue.

    Dude, I can think of thousands of scenarios. Say you have an application between A and B which does not have application level security FOR WHATEVER REASON, security did not matter initially, or it was not in the budget and IPSec was thought to be enough, or initially the data did not travel over the internet, or suddenly you want to tunnel another protocol over the internet, or suddenly your security precautions have increased, etc. IPsec can be deployed transparently without caring AT ALL about the upper layers, do you see the usefullness?

    One second you have an application without security, the next second everything you transmit is secured using state-of-the-art encryption! How can you not see the usefullness? Yes, you need an OS or hardware which does it for you, but it sure beats the heck out of adding security to both legacy and new developed software, if the security of IPSec is enough.