missing some rfc's

[danielguerra69]

When I check the wireshark code for stun, I see some more RFC's This is more a feature request.

• Please refer to the following specs for protocol detail:
  • • RFC 3489 (Addition of deprecated attributes for diagnostics purpose)
  • STUN - Simple Traversal of User Datagram Protocol (UDP)
  • Through Network Address Translators (NATs) (superseeded by RFC 5389)
  • • RFC 5389, formerly draft-ietf-behave-rfc3489bis-18
  • Session Traversal Utilities for NAT (STUN) (superseeded by RFC 8489)
  • • RFC 8489 Session Traversal Utilities for NAT (STUN)
  • • RFC 5780, formerly draft-ietf-behave-nat-behavior-discovery-08
  • NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
  • • RFC 5766, formerly draft-ietf-behave-turn-16
  • Traversal Using Relays around NAT (TURN) (superseeded by RFC 8656)
  • • RFC 8656 Traversal Using Relays around NAT (TURN)
  • • RFC 6062 Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
  • • RFC 6156, formerly draft-ietf-behave-turn-ipv6-11
  • Traversal Using Relays around NAT (TURN) Extension for IPv6
  • • RFC 5245, formerly draft-ietf-mmusic-ice-19
  • Interactive Connectivity Establishment (ICE)
  • • RFC 6544 TCP Candidates with Interactive Connectivity Establishment (ICE)

[keithjjones]

@danielguerra69 thanks for documenting this. Some things I noticed:

• RFC 5389 and RFC 8489 are already supported with this code (they are listed in the readme file).
• RFC 8489 obsoletes RFC 5389.
• You listed RFC 3489, but that is now obsolete by one we support.
• RFC 5245 is the ICE protocol. The example PCAP for this analyzer says it has ICE, and that is what I developed against. Not sure what this RFC has that is not supported by this code.
• RFC 5766 has some attributes, but they are already supported by this code.
• RFC 5780 defines a handful of new attributes.
• RFC 6062 has a couple of new methods and attributes.
• RFC 6156 is the TURN protocol. AFAIK - it was incorporated into STUN: https://wiki.wireshark.org/STUN
• RFC 6544 is ICE. Same comment as in RFC 5245, above.
• RFC 8656 has attributes that are already supported by this code. This also obsoletes RFC 5766 and 6156.

So it looks to me that there are a few attributes here and there that might need to be supported in RFC 5780 and 6062. What is it that you need supported? And in order to add support I will need publicly accessible PCAPs to develop against. Are you able to provide PCAPs with the structures you would like supported? Thanks.

[keithjjones]

Links:

• https://datatracker.ietf.org/doc/html/rfc3489
• https://datatracker.ietf.org/doc/html/rfc5766
• https://datatracker.ietf.org/doc/html/rfc5780
• https://datatracker.ietf.org/doc/html/rfc8656
• https://datatracker.ietf.org/doc/html/rfc6062
• https://datatracker.ietf.org/doc/html/rfc6156
• https://datatracker.ietf.org/doc/rfc5245/
• https://datatracker.ietf.org/doc/html/rfc6544
• https://datatracker.ietf.org/doc/html/rfc5389
• https://datatracker.ietf.org/doc/html/rfc8489

[keithjjones]

@danielguerra69 did this answer what you needed?

[danielguerra69]

I would have to do a deeper investigation into what application uses which stun rfc's. Most of the p2p voice applications use STUN. If have been running spicy and tshark on the same data and noticed a big gap in the results. I just saw that tshark is far more complete on it's RFC's in its source code. Wireshark doesn't show which rfc's where involved, maybe I could see it on the attributes. Here is an example for whatsapp, https://medium.com/@schirrmacher/analyzing-whatsapp-calls-176a9e776213. This document also discusses the relation between stun and (s)rtp. For facetime calls data is transported in stun itself. There are so many apps, all doing there own implementation. I will try to find the most used rfc's, but I think I could use all ;)

[keithjjones]

@danielguerra69 "If have been running spicy and tshark on the same data and noticed a big gap in the results." Did you mean "I have been running spicy and tshark on the same data and noticed a big gap in the results." If so, what gaps did you see? Do you have pcaps with these gaps you can share? That would make it easier for me to see what you are talking about.

The link you shared does discuss STUN, but it's only one protocol amongst many (like RTP and SRTP, both of which aren't STUN). I've actually done some research into WhatApp earlier this year and it uses chatd on TCP port 5222. I've studied pcaps with this traffic. The data is definitely not STUN. They said it is the Signal protocol: https://signal.org/blog/whatsapp-complete/ The signal protocol is also listed in the article you shared:

I also noticed in the link you shared it said this:

Going to https://www.pjsip.org/ it says:

This also looks like they have other protocols to support data transfer outside of STUN (or ICE, or TURN): SIP, SDP, RTP. If applications use those protocols to communicate after determining NAT information with STUN, that would require a different Zeek protocol analyzer to parse them. SIP is already supported in base Zeek: https://github.com/zeek/zeek/tree/master/src/analyzer/protocol/sip

The overview section here has a good explanation for STUN, ICE, and TURN:

https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment

In the traffic I've seen, STUN uses information it finds out about NATs to tell other protocols which ports and IP addresses to use. That's what the code here supports.

I'm happy to try to include what you need if I a) know exactly what's missing that you need, and b) I have something to develop against like a PCAP.