[tram] Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-tram-stun-origin-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a bit of a weird DISCUSS since I didn't manage to ballot when the
document was first on the IESG's agenda, so I'm coming in mid-stream.

I support Stephen's DISCUSS. If Alan's proposed changes make it into the
document, they would resolve most of my concerns. However, I still see a
problem with this proposed new text:

"For STUN requests sent without authentication to a STUN server (i.e.

   STUN binding requests sent to a STUN server), the STUN client SHOULD 

   include the ORIGIN attribute.  The ORIGIN attribute MUST NOT be
included 

   if it is a "privacy-sensitive" context, as discussed in the Security
Considerations

   section."

For requests sent with authentication, I understand that the origin
attribute needs to be accurate in order for the client to authenticate.
In those cases, the STUN server can rely on the attribute it receives.
But for requests without authentication, what prevents the client from
lying? And if those requests are not (D)TLS-protected, what prevents them
from being modified in transit? I understand Alan to be saying that the
justification for the origin in this case is operational troubleshooting,
but if the server can't rely on the origin it receives, doesn't that make
it risky for the server to act on that information?

My additional concern is about the use of "logging" as a justification
for including and origin attribute. Logging in and of itself is not a
reasonable justification. Alan's mail discussed the use of the origin for
operational troubleshooting, which seems like what might actually be
intended instead of "logging." In any event the purpose for the logging
either needs to be explained or "logging" should not be listed as a
justification.