Subject: RE: [MMUSIC] Prelim copy of comedia-02 available

From: "David Yon" <[email-masked]>
Date: Fri, 12 Apr 2002 16:33:20 -0400

> 
> >>  - In section 3, how is the source address useful given 
> that it can't be
> >>    trusted? More explanation of how it can be used is 
> probably needed.
> >
> >There is a big "NOTE:" section in "Source-Address 
> Considerations" that
> >covers this.  What am I missing?
> 
> Do either of those uses make sense if the source address can 
> be spoofed?
> Firewalls that open ported based on untrusted SDP seem to be 
> a risk, and
> you list problems with session identification. I just think 
> it could do
> with more discussion of the risks and benefits tradeoff, 
> maybe something
> in the security considerations.
> 

The firewall security issue is a good point.  The dynamic NAT mapping
isn't really a security issue as a generic NAT function isn't intended
to offer security.  For example, my SMC Barricade allows me to specify
dynamic bindings that are created in response to other network activity,
none of it validated or "trusted".  In such a scenario, an internal ALP
in the NAT box that translates the source address/port and sets up a
dynamic mapping would be perfectly appropriate.

For firewalls, SDP being untrusted is not a given.  There could be a
chain of trust from the firewall to the local SIP proxy back to
trusted/authenticated UA's where the SDP originates.  I can add a
general comment in the security considerations that mentions that in the
case of dynamic firewall pinholes that the trust/spoofing issues must be
taken into account.

Does that address your concern?

> >>  - Section 4.1: the time window is the t= line?
> >
> >The t= line is not directly referenced since I believe the endpoint's
> >time window semantics can be derived from other sources (SIP Session
> >Timer comes to mind).
> 
> Okay, but what if the t= line contradicts? Which takes precedence?
> 

That's context specific, and it's outside of comedia's scope.  The point
I'm driving at is that the endpoints have *somehow* unambiguously
communicated to each other a time window.  SDP's t= line is but one
place that this happens.  Comedia cannot dictate when t= does or does
not take precedence.

Another way to look at it: in whatever manner the endpoints communicate
this time window, comedia changes nothing about the semantics of said
time window nor how it should be communicated.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Fri, 12 Apr 2002 17:17:48 -0400

>Does that address your concern?

Yes.

>time window nor how it should be communicated.

Okay.

Colin