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

[Alissa Cooper <[e-mail]>]

If some of this context could be added to the draft, I think that would be much better than just saying "logging and analytics."

Thanks,
Alissa

> On May 11, 2015, at 6:04 PM, Yoakum, John H (John) <[e-mail]> wrote:
> 
> There seems to be some questions around why things like logging and administrative debugging are useful and possibly some of it is a matter of context.  Inside enterprises it is very common to have a variety of logging capabilities across all parts of a system or solution as well as to perform debugging activities based on whatever combinations of insight are available whenever problems occur.  
> 
> With WebRTC is will be very common to find TURN servers run by enterprises to serve various enterprise-centric websites that desire real-time communications as part of the enterprise web experience for people from outside the enterprise who may be external parties or in many use cases may actually be enterprise employees.  ORIGN tells a STUN or TURN server what realm is associated with the request.  That piece of knowledge is already well known by the browser making the request (except in the privacy-sensitive situations accommodated in the draft, which will seldom be the case for employees of an enterprises) and is highly useful to enterprises who have web services and related communications enablement gear like STUN and TURN servers necessary to allow employees access from home, virtual offices, or while traveling (without the need for VPNs or other specialized network connections).  Large enterprises often have multiple applications, multiple domains or subdomains, and multiple realms.  This simple extension to STUN to conveys insight related to the web applications using communications ennoblements like STUN and TURN servers will find many uses inside enterprises.
> 
> ORIGIN is not a substitute for more accurate authentication, it is a way to quickly determine the best authentication to attempt as well as to quickly filter out things where authentication attempts or other processing (even simple STUN requests) are a waste of resources as that realm will never be serviced anyway.
> 
> In terms of troubleshooting, within an enterprise it is highly useful to look at insight from all the parts of a solution and identify inconsistences.  As an example if it is discovered while debugging a communications failure that a browser inside an enterprise is lying about ORIGIN it may help in uncovering that the browser has been compromised by malware.  Enterprises can never have too much insight in their logs for short periods of time as that is what they rely on to debug sophisticated systems.  Just as importantly log data is often used to judge system usage to help justify investing in additional resources or spread costs to the applications or departments involved.
> 
> Is any of this enterprise perspective helpful or just adding to the confusion?  One of the great promises of WebRTC is to allow simpler systems without all the complicated telephony approaches from the past and capitalizing on simple web-centric concepts like ORIGIN is one great enabler.  This draft even extends these more modern concepts to things like SIP to help simplify some of the more conventional technologies.
> 
> 
> Cheers,
> John
> 
> AVAYA
> 1.919.425.8446 
> 
> 
> -----Original Message-----
> From: Alissa Cooper [mailto:[e-mail]] 
> Sent: Monday, May 11, 2015 7:30 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Alissa Cooper's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS)
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=AwICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=O4OIzAW7EVPxOEhYXzj7Eg&m=UUw6tlPYwiPTqTiPb-8d0JzXAshUyyMqbEveZ1APHyg&s=7-Ky3gBkj-nh5lszKh8A2T5LKV9tUum5QpJKbNUFUeM&e=
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtram-2Dstun-2Dorigin_&d=AwICaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=O4OIzAW7EVPxOEhYXzj7Eg&m=UUw6tlPYwiPTqTiPb-8d0JzXAshUyyMqbEveZ1APHyg&s=qyAN_jyGYafpPgJ3Hxg9bybo3UDOUHoCxUU2CZhcpmQ&e= 
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 
> 
>