> I found the idea of tagging in PF very interesting, and we are > interesting in using it for policy definitions, but here is the deal: > OVER THE INTERNET!...i know i know....the "panipulated " or tagged > packets, wil be capsulated into Ipsec...so problems like fragmantation > or routers shouldn'T be the problem. And on the other side would be an > "interpreter" or "translater" who "encodes" the tags off the packets. > > It is thought to be used on ipsec gateways or ipsec brisges. > > now my question is: > > 1. Which code part of pf is responsible for such a thing? (our part > will be doing it on userspace level, and not kernelspace) > > > 2. What do you think would be problem, for the packets "on the way"? i > thought since they are capsulated, it should not be a problem...and on > receiver side, the packets would be joint again 8the fragmented > packets) and forwarded to client (behind bridge or gateway)
there is already some kind of tagging in IP: tos value. unfortunately, pf can not handle tos value for own purposes. from the other side, tos width is 4 bits only so it can not handle much of useful information (pf tags, for example). additionally, the way, the routers over the world can interpret tos value, is unpredictable. but what is tos? this is the way to mark some traffic basically done by the looking flow's source port and destination ports, port and destination addresses and etc. so pf does with it's own tagging. yes, you can not handle different raw flow's within the incapsulated flow. but what's the point? you can priorize them on the sender side by doing tagging on encapsulation interface and altq'ing them later on the physical device accordingly to tags. on the receiver side, the tags "on the wire" are useful, as no way to priorize incoming traffic. but again you can sort raw flows on the incapsulation device and priorize them while passing back to client. yes, you should do this twice. but this is acceptable price. just imagine, what routers between your sender and receiver may have different opinion about priorizing your traffic than you :)
