Re: [AVT] Open issues in the PortMapping draft

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Tom,

> -----Original Message-----
> From: Van Caenegem, Tom (Tom) [mailto:[e-mail]]
> Sent: Friday, May 21, 2010 9:23 AM
> To: Ali C. Begen (abegen); IETF AVT WG
> Subject: RE: [AVT] Open issues in the PortMapping draft
> 
> Hi Ali,
> 
> Some comments :
> -related to your question 5: it makes more sense to include in the portmapping response message a
> response field that could be used to contain error codes similar as was defined for RAMS-I. I do not
> think you can impose timing requirements to an RS when responding to a port mapping response, other
> than the usual RTP AVPF timing rules.
> -I would favour to keep "port mapping response" message as a name, whereas  a new message is defined,
> entitled e.g. "port mapping cookie" , to transfer the cookie along with a RAMS-R or NACK.  The only
> difference may be the response field presence, but it makes it easier to present this solution.

OK, any other opinions on this?

> -If the port mapping request is sent several times by the RTP receiver (redundancy reasons), how
> should the RS react? You should also state that the random number inside the port mapping request must
> then be kept the same.

Thinking more about this, I don’t think we need to have a random number and we can safely remove it from the cookie.
 
> Then a comment with the risk of being criticised as counter-productive.;-)
> 
> I notice that you know stipulate that the SSRC name in SDES message accompanying RTCP messages in the
> primary RTP ssm session and accompanying the RTCP messages in the unicast RTP retransmission sessions
> must be used by the RS to associate them together. For this reason you also submitted the draft-begen-
> avt-rtp-cnames, an effort I applaude!

Thanks, that should resolve the CNAME issues. But on the cookie side, I don't think we need CNAMEs in the hashing, either.
 
> But... The reason why the simpler non-cookie solution I proposed  to enable the port mapping, was
> turned down in Anaheim was exactly because the association of the RTCP messages in the two sessions
> had to be done via C-NAME, but as it could not be guaranteed that C-NAMES were unique, the solution
> could not be guaranteed to work well in all cases.
> 
> Because the cookie-based solution clearly has some disadvantages compared to not using cookies
> (additional RTT impacting channel change time, server that needs to generate cookies, need for a keep-
> alive mechanism and additional security threats like stealing cookies etc ) I wonder what the
> remaining rationale is for not defining the non-cookie approach in IETF for RAMS and retransmissions.

I believe we can combine your http://www.ietf.org/proceedings/77/slides/avt-10.pdf idea with the cookie proposal.

This will avoid sending the keep-alives, while still getting the security benefit of the cookies proving return routability (which prevents the attack Magnus described in http://www.ietf.org/mail-archive/web/avt/current/msg12617.html). This way, the client needs only a single cookie (can obtain at boot time) regardless of how many different local ports it uses (in the current scheme we need one cookie per local port).

I'll email you offline to set up a time to talk.

-acbegen
 
> Regards
> Tom