TURN server should return 420 (Unknown attribute) when it sees unexpected attribute #76

Activity

1. Sean-Der commented on Dec 3, 2025

   

   Sean-Der

   on Dec 3, 2025

   Member

   More actions

   Handling of attributes is defined in RFC 8489 like so

      If the request contains one or more unknown comprehension-required
      attributes, the server replies with an error response with an error
      code of 420 (Unknown Attribute) and includes an UNKNOWN-ATTRIBUTES
      attribute in the response that lists the unknown comprehension-
      required attributes.
   

   The following logic is already available in pion/stun.

   To allow future revisions of this specification to add new attributes
      if needed, the attribute space is divided into two ranges.
      Attributes with type values between 0x0000 and 0x7FFF are
      comprehension-required attributes, which means that the STUN agent
      cannot successfully process the message unless it understands the
      attribute.  Attributes with type values between 0x8000 and 0xFFFF are
      comprehension-optional attributes, which means that those attributes
      can be ignored by the STUN agent if it does not understand them.
   

   So we need to process/handle STUN packets in our Client+Server and if we get an attribute we don't understand return a 420
2. rg0now commented on Dec 3, 2025

   

   rg0now

   on Dec 3, 2025

   Contributor

   More actions

   As per handling unknown attributes, I agree with @Sean-Der: we should reject unknown comprehension-required attributes with an error code of 420 (Unknown Attribute) and include an UNKNOWN-ATTRIBUTES attribute in the response, and we should silently ignore the rest.

   As per implementing this in pion/stun: it seems all machinery is in-place, we even have func (AttrType) Required() and func (AttrType) Optional() implemented, and we have const AttrUnknownAttributes AttrType = 0x000A defined. What's missing is the actual implementation of the correct attribute handling logic. What's the most pion-y way to make this work? Should we manually inject the unknown attribute logic at each call site where we deal with message parsing? Or should we inject this into func (m *Message) Parse(getters ...Getter) error and move from per-attribute parsing in pion/stun and pion/turn to calling message.Parse first? Or should we automate this in some other way?
3. Sean-Der

   added 8 commits that reference this issue on Dec 5, 2025

   Add AttrType.Valid method

   ...

   3d03865

   Add AttrType.Known method

   ...

   ed64e5d

   Add AttrType.Known method

   ...

   e48a999

   Add AttrType.Known method

   ...

   9b2d7bc

   Add Unknown Attribute Handler

   ...

   ed0d02b

   Add Unknown Attribute Handler

   ...

   40b1c36

   Add Unknown Attribute Handler

   ...

   cb1fd32

   Add Unknown Attribute Handler

   ...

   45bc23d
4. Sean-Der

   closed this as completedin #486on Dec 9, 2025