Wow! You read the draft! Well then, on that particular draft, you probably
noticed that diameter does not run over UDP anymore *grin*.
I do agree with your packet detection changes, and I could have the radius
dissector call the diameter dissector. That would be pretty easy. And,
now that I think about it, pretty graceful. I wanted to keep the
dissectors seperate, since diameter will be moving off of UDP very soon.
Right now, I needed the sniffer for the UDP version. Soon, I'll need to
dissect TCP and then SCTP packets.
I'll post the new version (where the radius dissector spawns the DIAMETER
dissector) sometime next week, as I get tired of reading drafts. I'm way
behind and the ietf meeting is coming up fast!
P.S. I'll remove the DIAMETER port preference, but leave the RADIUS ones
in. Many people run DIAMETER on different udp ports.
On Thu, Jul 20, 2000 at 09:01:38PM -0700, Guy Harris wrote:
> On Tue, Jun 27, 2000 at 04:43:00PM -0500, David Frascone wrote:
> > 1) DIAMETER can run on any port (it's configurable), and the most common
> > port to run on is the RADIUS port. How can I register two protocols
> > types to the same UDP port? (If it is a DIAMETER message, the first
> > byte is 0xfe) For now, I'm using a secondary port, 2645.
>
> Given that
>
> ftp://ftp.isi.edu/internet-drafts/draft-calhoun-diameter-16.txt
>
> says
>
> RADIUS PCC
> The RADIUS Packet Compatibility Code (PCC) field is a one octet
> field which is used for backward compatibility with RADIUS and
> MUST be set to 254. In order to easily distinguish DIAMETER
> messages from RADIUS, the value of 254 has been reserved and
> allows implementations to support both protocols by using the
> first octet in the header.
>
> this indicates that, at least for port 1812, the correct behavior of a
> dissector would be to check whether the first octet is 254; if so, treat
> the packet as DIAMETER, otherwise treat it as RADIUS, to handle
> implementations that support both protocols.
>
> For other ports (e.g. 1645, which RFC 2138 says was used for "the early
> deployment of RADIUS", which was an error as that was used by the
> "datametrics" service), either the same strategy could be used, or the
> packets could be handed to an always-RADIUS or always-DIAMETER
> dissector.
>
> So a dissector function would be registered for UDP port 1812 which
> checks the first octet of the packet, and:
>
> if it's 254, dissects it as DIAMETER;
>
> if it's not 254, hands it to the RADIUS dissector.
>
> This would neither require registering two protocols for the same UDP
> port nor having dissectors return Boolean values.
>
> It's not a general solution, but I'm not sure whether there *is* a
> general solution; in this particular case, the draft in question
> indicates how the port conflict is to be resolved, which may not apply
> to other port conflicts.