winscape 2324

The problem is packets can be "bad" for a variety of reasons buttociated with different parts of the network stack; IP addresses can be wrong, easy enough for a firewall to catch, protocol state flags can be wrong- somewhat harder but a sufficiently smart firewall can do that sort of thing for protocols such as TCP. OTOH how can a firewall know how to validate the application data payload- or for that matter, the validity of a whole set of packets forming some complex transaction in the application itself?

It seems to me the solution is to test "validity" at each layer the packet traverses; in the IP layer, check the addresses, at the transport, check the protocol flags, etc..- at the application layer, the application checks that the transaction is OK. Thats not to say the application can't do additional tests with the addresses and protocols, but in doing so it has to pay the design price of being more or less intimately aware of all the data transport mechanisms used to communicate with it. At least with sockets based stuff the design price is more or less already paid by virtue of using the IP stack in the first place, though I think the prevalence of of the INET family addresses and protocols has probably significantly short-circuited whatever independence the socket architecture did afford- ther's a lot of hard-coded sockets parameters and IP address parsing code out there.

The key to handling this without a design falling into chaos seems fundamentally related to maintaining symmetry between the sender and receiver; if you conflate layer functions on one side to take a shortcut, it'll come back to bite you later- up to and including major refactoring because the data model is found to be incorrect late in game.

Gregm