- This topic has 6 replies, 2 voices, and was last updated 16 years, 2 months ago by
.
-
Posts
-
I have developed an application to encrypt network traffic via an NDIS driver. I currently change the IP protocol from 6 to 99. This allows me to identify packets that I have modified/encrypted. The problem is most routers do not recognize protocol 99 and kills/stops the packet from being sent. I have looked at the IP options, but I am not sure of the proper way to modify the IP options. Based on what I have read I should be able to add my options with out changing other options already set. Can someone tell me have to understand how options are set and what they mean. for example IP Option “608038481”, how does these option break down.
First of all I would recommend to use one of the known protocols to tunnel encrypted packets. There are several options and all of them will be successfully processed by routers:
1) IPSEC ESP protocol
2) GRE
3) IP-in-IP
4) IP-in-UDPAs an example you can look at the GRETunnel sample from WinpkFilter samples set. It does not actually encrypt the tunneled packet but it is fairly simple to add encryption. If you need to have an extra information attached to the packet you can also use extended GRE.
Why do you want to add/change IP options? If you want to add extra encryption related information to the packet there are other possibilities.
Some of my customers want to use my application to encrypt video to a public IP. The problem is some routers have been configure to block most protocols except TCP taffic. So I want to explore other ways I can identify packets that I have changed/encrypted. The routers that I am dealing with seem to drop packets that have a protocol that they do not identify. I believe having an option to place an identifier in the options will allow me to make my application more robust. If there are yet better options out there to accomplish the same goal of identifying packets that I modify, please tell me about it. I do realize that using a common protocol like IPSEC may get me through the router, but it may confuse traffic as well. My encryption solution is disruptive and does not fall into the normal encryption schema.
I currently insert my special header into the packet, so all the information needed to decrypt the packet is already there. I currently change the protocol from 6 to 99 so that I can identify packets that I have changed.
The problem is some routers have been configure to block most protocols except TCP taffic.
In this case you may want to tunnel packets inside the SSL stream over TCP. An example, this method is used in http://www.projectloki.com VPN solution.
I do realize that using a common protocol like IPSEC may get me through the router, but it may confuse traffic as well. My encryption solution is disruptive and does not fall into the normal encryption schema.
Why not to use GRE tunneling then? Routers usually pass GRE and even may NAT if you use extended GRE header.
- You must be logged in to reply to this topic.