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

From: "David Yon" <[email-masked]>
Date: Mon, 15 Apr 2002 08:39:42 -0400

Colin, thanks again for the timely and detailed feedback.  I've posted
an updated copy at:

http://www.dialout.net/public/ietf/draft-ietf-mmusic-sdp-comedia-02.txt

This copy has incorporated all feedback to date.  I will fix the
non-ASCII character problem when I submit the official copy.

Jeorg/Colin, ready for Last Call?  Should I go ahead and submit this
version to the ID queue?

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Friday, April 12, 2002 5:18 PM
> To: David Yon
> Cc: [email-masked]; Rohan Mahy
> Subject: Re: [MMUSIC] Prelim copy of comedia-02 available 
> 
> 
> --> "David Yon" writes:
> >> 
> >> >>  - 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?
> 
> Yes.
> 
> >> >>  - 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.
> 
> Okay.
> 
> Colin
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 Apr 2002 13:50:04 -0400

>Jeorg/Colin, ready for Last Call?  Should I go ahead and submit this

Yes, please submit it to the i-d archive. 

Colin