Format an IP packet with an invisible 2nd payload?
I think this is a question about IP packet headers—Can anyone think of a way to format an IP packet so that it would successfully be passed through all existing telecom equipment out there (that currently passes or routes IP packets), but contains a 2nd payload that specialized equipment could read? It's a matter of adding a non-trivial chunk of data (300-600 bytes) that wouldn't interfere with the normal routing of the packet or be mistaken as part of the standard IP payload as it traveled to its destination. The options field (when the Internet Header Length is > 5) might be exactly the type of thing I was hoping for, except IP packet format doesn't permit it to be anywhere nearly as long as it would need to be.
Presumably, it wouldn't work to include the extra data in the standard IP payload, because whenever the final recipient had normal rather than specialized equipment it would fail to correctly recognize the standard IP payload correctly. However, it can't (for example) be appended to the IP packet wantonly, because then the packet length would be wrong and it would all just be dropped (presumably by the first piece of standard equipment it encountered). So I conclude that it can only be done with a legally formatted IP packet.
Also, if the final recipient didn't have the specialized equipment, it would need to be handled as if it contained no 2nd payload. That is, the packet minus its specialized data would still need to be a valid "normal" packet.
Ideally, the extra data could be added to every packet, but if that is just impossible, then I wonder if it would be possible to meet the constraints above through adding an additional fragment packet.
Could you tell a bit more on why you want to do this? As I do not think you will find a solution on the path you are proposing. You might be able to use an IPv6 extension header to do this, but of course you would be limited to IPv6 only traffic (and I'm not sure there are private extension header options available).
Here's another way to ask my question: A message travels over the Internet toward its destination. At some of the nodes, the routing equipment has a specialized modification called ModX. ModX's function is to add 8 to 32 bytes of metadata known only at that node. However, the nodes without ModX need to process the message normally (as if it had no metadata), but at the same time must preserve the metadata and pass it on to the next node.
What is the absolute lowest OSI Layer this can be accomplished at? —taking into account that it must continue to work with the equipment & software currently in service all over the world. An inelegant solution would be OK.
The metadata would include security hinting data by the node about the sender (the previous node) of the packet(s). Theoretically, adding it to Ethernet packets (whose MTU is ...(more)
As far as I know, this is exactly how IPv6 extension headers work. A header can be added to the packet and it can indicate that all intermediate nodes must forward the header, even if they do not support it themselves. But in IPv4 there is no such thing as far as I know.
Tweaking something on top of standards will result in unpredicted behavior on nodes that are not under your control.
Some questions:
I am trying to figure out how a node can evaluate an incoming message for whether it came from a trustworthy sender or not (known hacker addresses would be examples of untrustworthy senders). It can then decide whether the message should be passed on or dropped. It needn't be a black and white evaluation, it could indicate the likelihood that sender would only send packets without harmful effects.
Ultimately, it would be the most flexible if all nodes were able to evaluate the security hints, because each may want to evaluate the metadata according to custom criteria.
A more restricted scheme would be for nodes that want to use the metadata to upgrade to be able to use it. This could be done, for example, for the nodes in each of two countries that are connected by a trunk. I think one could think of this as just supporting ...(more)