Feature request: conditional run dissector on traffic

[qnet-herwin]

It has been mentioned briefly in #471: with the option -T radius it is possible to dissect traffic over non-RADIUS ports as RADIUS, but this means all traffic will be dissected as RADIUS.

A short use case as an example: FreeRADIUS has the possibility to use a RESTful server for authorization. My RESTful daemon will send a CoA/Disconnect if this user still has another session, and my NAS requires that I send it to port 1700 instead of the standard port. I want to see all the traffic that is relevant, which means UDP port 1812 for RADIUS authentication, TCP port 80 for the RESTful traffic and UDP port 1700 for RADIUS CoA/Disconnect.

Until yesterday, UDP port 1700 was not marked as RADIUS, which means that would not be dissected. If I use -T radius, all traffic would be dissected as RADIUS, so the HTTP traffic would be mangled.

It would be nice if there was a possibility to conditionally mark traffic as a certain protocol, like saying -T "udp port 1700 = radius, tcp port 4080 = http"

[mcr]

> It has been mentioned briefly in #471: with the option -T radius it is
> possible to dissect traffic over non-RADIUS ports as RADIUS, but this
> means all traffic will be dissected as RADIUS

> A short use case as an example: FreeRADIUS has the possibility to use a
> RESTful server for authorization My RESTful daemon will send a
> CoA/Disconnect if this user still has another session, and my NAS
> requires that I send it to port 1700 instead of the standard port I
> want to see all the traffic that is relevant, which means UDP port 1812
> for RADIUS authentication, TCP port 80 for the RESTful traffic and UDP
> port 1700 for RADIUS CoA/Disconnect

> Until yesterday, UDP port 1700 was not marked as RADIUS, which means
> that would not be dissected If I use -T radius, all traffic would be
> dissected as RADIUS, so the HTTP traffic would be mangled

> It would be nice if there was a possibility to conditionally mark
> traffic as a certain protocol, like saying -T "udp port 1700 = radius,
> tcp port 4080 = http"

Being able to dynamically map ports -> protocols in TCPDUMP would indeed be a nice thing to have. I think that squishing it all into -T is too hard. I'd rather have a file that describes the mapping, and just bake a file like that in as the default. As for a syntax... I was thinking that maybe we could use pcap filters as the matchers.

] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[guyharris]

There should probably be a command-line option as well, so you don't have to change the file; the file would be for more persistent port mappings.

[mcr]

Skickat från min Sony Xperia™-smartphone

---- Michael Richardson skrev ----

It has been mentioned briefly in #471: with the option -T radius it is

possible to dissect traffic over non-RADIUS ports as RADIUS, but this means all traffic will be dissected as RADIUS

> A short use case as an example: FreeRADIUS has the possibility to use a
> RESTful server for authorization My RESTful daemon will send a
> CoA/Disconnect if this user still has another session, and my NAS
> requires that I send it to port 1700 instead of the standard port I
> want to see all the traffic that is relevant, which means UDP port 1812
> for RADIUS authentication, TCP port 80 for the RESTful traffic and UDP
> port 1700 for RADIUS CoA/Disconnect

> Until yesterday, UDP port 1700 was not marked as RADIUS, which means
> that would not be dissected If I use -T radius, all traffic would be
> dissected as RADIUS, so the HTTP traffic would be mangled

> It would be nice if there was a possibility to conditionally mark
> traffic as a certain protocol, like saying -T "udp port 1700 = radius,
> tcp port 4080 = http"

Being able to dynamically map ports -> protocols in TCPDUMP would indeed be a nice thing to have. I think that squishing it all into -T is too hard. I'd rather have a file that describes the mapping, and just bake a file like that in as the default. As for a syntax... I was thinking that maybe we could use pcap filters as the matchers.

Having port maping in a pcap-ng block might be a nice feature too which might be worth considering when designing the format. Regards Anders

] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

---

tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[mcr]

Guy Harris notifications@github.com wrote:

There should probably be a command-line option as well, so you don't have to change the file; the file would be for more persistent port mappings.

Yes, I agree, it should take what would be a single rule in the file, and could be repeated. This gets annoying really quickly, but it's good for short things.

] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[infrastation]

A related useful idea mentioned in #471 would be easier to implement. The -T option forces netdissect to treat all or most packets as the given protocol before it reaches a normal switch that dispatches more-specific functions. In addition to that it is possible to introduce a similar option like --last-resort or --decode-unknown-as or --default-protocol, which would work as the default case in the switch and not instead of the switch block.