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

Brandon,

Thanks for sending your comments to the list.  We'll get answers to you
soon, along with some discussion about the HOST alternative that has been
raised.

- Alan -

On Tue, Nov 10, 2015 at 3:33 PM, Brandon Williams <
brandon.williams@akamai.com> wrote:

> 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
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>