[tram] draft-ietf-tram-stun-origin-06.txt review

[Brandon Williams <[e-mail]>]

Here's the review that I promised to write up. Sorry I didn't get it out
before the meeting.

I already raised my biggest concerns in the meeting last week, but will
repeat them for the list:

* Although I understand the privacy concerns that have been raised, I
think that the new "Origin Matching Rules" makes the attribute enough
less useful that I likely would not implement support. We do some fairly
unique things for client-specific relay mapping, so I understand if I'm
in the minority on this point, and I don't consider the draft bad to
publish if there are enough others who still consider it useful with
this limitation.

* I am concerned that some of the suggested uses for the attribute
provide an incentive to lie. I'm not convinced by the argument that the
system won't work if you lie, because there is no requirement to use
ORIGIN as a realm selector for auth purposes. As a result, the client
could lie in order to get through a related firewall restriction or to
get around a service limitation on the relay.

OK, as for the minor comments ...

S2.2 The new text requires the client to send ORIGIN in any case that
matches the constraints in S2.1. The old text only required it for web
origins and only recommended it for others. What's the reason for the
change? The section would benefit from a rationale for the MUST.

S2.3 The same comment about changed requirements and providing a
rationale applies.

S4 This probably should have occurred to me in earlier reviews, but I
now see that the Security Considerations section conflicts with the
requirements text in S2.2 and S2.3. The earlier sections require ORIGIN
to be sent in some messages where Security Considerations directly
allows it to be omitted if not using (D)TLS. It's a little confusing for
it to be expressed as required in one place and not required in another.


That's it. Please let me know if you have any questions about the above.

--Brandon