Subject: Re: [AVT] Consensus call - Token approach withindraft-ietf-avt-ports-for-ucast-mcast-rtp

From: Roni Even <[email-masked]>
Date: Thu, 07 Oct 2010 18:21:45 +0200

Hi Glen,
I will try to clarify the issue.

The Port Mapping Between Unicast and Multicast RTP Sessions described in
http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 was
discussed for a couple of IETF meeting and on the list. The initial approach
that was agreed after we had a breakout session in previous IETF meeting was
to use a cookie based solution even though it required more messages and you
needed a cookie for every RTP session. 

Before the last IETF meeting there were proposal to update the solution to a
token approach.
In the token approach:
- Tokens are port-independent (cookies are port-dependent) and only depend
on the client's IP. That is, once a client gets its token, it can use it
with any of its ports and with any Feedback Target.
- Tokens address the concern raised by Magnus
(http://www.ietf.org/mail-archive/web/avt/current/msg12617.html)
- No need for keep-alives

We had a discussion in Maastricht and the outcome is in
http://www.ietf.org/proceedings/78/minutes/avt.txt 

There is a concern about the token solution as mentioned in the minutes in
section 9 of
http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 

My understanding is that people wanted a token based solution but there are
two approaches

1. Use the token only solution

2. Use a combination when if the request has only an IP address the response
will be a token and if it will have both IP address and port the response
will be a  cookie.

According to the minutes the support is for the second approach.

We were trying to ask the list if this approach is OK. 

It is true that the begen individual draft as currently written is not a
full replacement of the WG draft.

Roni Even
AVT co-chair

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Glen Zorn
> Sent: Friday, September 17, 2010 8:18 AM
> To: 'Ali C. Begen (abegen)'; 'DRAGE, Keith (Keith)'
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] Consensus call - Token approach withindraft-ietf-
> avt-ports-for-ucast-mcast-rtp
> 
> Ali C. Begen (abegen) [mailto://[email-masked]] writes:
> 
> ...
> 
> > > 1) Incorporate material from draft-begen-avt-token-for-portmapping-
> 01
> > into
> > > draft-ietf-avt-ports-for-ucast-mcast-rtp
> >
> > The token draft, IMHO, is good enough and addresses our issues
> > adequately. If we agree with this, we can simply continue working on
> it
> > and finish the work.
> >
> > If we disagree with this and think Cookie is what we need, then we
> > finish the Cookie draft.
> 
> Maybe I'm wrong but it sounds like you are proposing the wholesale
> replacement of the text of a WG document with that your own individual
> submission.  It seems to me that in order for this to be a reasonable
> course
> the replacement text would need to be far superior to the existing
> draft,
> not just good enough/adequate for the purpose, unless, of course, the
> existing WG draft is not good enough or inadequate; but if that is the
> case,
> it begs the question how it became a WG draft in the first place.
> Furthermore, I would expect that such an outcome would necessarily be
> the
> result of strong consensus in the WG, not merely the absence of
> complaint...
> 
> ...
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Fri, 08 Oct 2010 10:47:16 +0200

Hi guys,
There were some concerns about how we drafted the consensus call so I would
like to try and give it another try.  Sorry for the long message which I
hope will clarify what are the proposed options. We would like to get
feedback by October 18th.

The Port Mapping Between Unicast and Multicast RTP Sessions described in
http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 was
discussed for a couple of IETF meeting and on the list. The initial approach
that was agreed after we had a breakout session in previous IETF meetings
was to use a cookie based solution even though it required more messages and
you needed a cookie for every RTP session. 

Before the last IETF meeting there were two proposals to update the solution
to a token based approach.

In the token approach:

We had a discussion in Maastricht and the outcome is in the meeting minutes
http://www.ietf.org/proceedings/78/minutes/avt.txt (see the section on
draft-begen-avt-token-for-portmapping). The token draft has Dan Wing (who is
also BEHAVE co-chair) as a co-author and he looked at the solution verifying
that it will work well with NATs

At the meeting the preference was for a token based solution but there are
were two approaches discussed.

According to the minutes the support was for the second approach. The major
reason was a concern that carrier grade NATs can allocate more than one IP
address as the public address.

The authors of
http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01 suggest
that they addressed the concerns about the token only solution (see section
9 of the draft) and prefer to have a token only solution. This is a change
from the meeting minutes and this is the reason for the second question in
this consensus call.

So here are two questions for the group !!!

1. Do the people in the mailing list support the proposal to use a token
based solution instead on the cookie one. (this was the preference in the
consensus call in Maastricht) and we would like to confirm it on the list.

2. We have two options for the token approach, please give your preferences.

2.1 Token only solution as proposed in
http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01
2.2 Token + cookie, in this case if the request will include only IP address
the response is a token, if it also includes a port it will be a cookie.
This approach is for cases were the NAT may use more than one IP address for
mapping a local address.

Please respond even if you did it on the previous consensus call.

Roni Even
AVT co-chair

---

From: Colin Perkins <[email-masked]>
Date: Mon, 11 Oct 2010 17:50:31 +0100

On 8 Oct 2010, at 09:47, Roni Even wrote:
> There were some concerns about how we drafted the consensus call so  
> I would like to try and give it another try.  Sorry for the long  
> message which I hope will clarify what are the proposed options. We  
> would like to get feedback by October 18th.
>
>
> The Port Mapping Between Unicast and Multicast RTP Sessions  
> described in http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02 
>  was discussed for a couple of IETF meeting and on the list. The  
> initial approach that was agreed after we had a breakout session in  
> previous IETF meetings was to use a cookie based solution even  
> though it required more messages and you needed a cookie for every  
> RTP session.
>
> Before the last IETF meeting there were two proposals to update the  
> solution to a token based approach.
>
> In the token approach:
> - Tokens are port-independent (cookies are port-dependent) and only  
> depend on the client's IP. That is, once a client gets its token, it  
> can use it with any of its ports and with any Feedback Target.
> - Tokens address the concern raised by Magnus (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html 
> )
> We had a discussion in Maastricht and the outcome is in the meeting  
> minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the  
> section on draft-begen-avt-token-for-portmapping). The token draft  
> has Dan Wing (who is also BEHAVE co-chair) as a co-author and he  
> looked at the solution verifying that it will work well with NATs
>
>
> At the meeting the preference was for a token based solution but  
> there are were two approaches discussed.
>
> 2. Use a combination when if the request has only an IP address the  
> response will be a token and if it will have both IP address and  
> port the response will be a  cookie.
>
> According to the minutes the support was for the second approach.  
> The major reason was a concern that carrier grade NATs can allocate  
> more than one IP address as the public address.
>
> The authors of
> suggest that they addressed the concerns about the token only  
> solution (see section 9 of the draft) and prefer to have a token  
> only solution. This is a change from the meeting minutes and this is  
> the reason for the second question in this consensus call.
>
> 1. Do the people in the mailing list support the proposal to use a  
> token based solution instead on the cookie one. (this was the  
> preference in the consensus call in Maastricht) and we would like to  
> confirm it on the list.
>
> 2.2 Token + cookie, in this case if the request will include only IP  
> address the response is a token, if it also includes a port it will  
> be a cookie. This approach is for cases were the NAT may use more  
> than one IP address for mapping a local address.
>
>

The approach in draft-begen-avt-token-for-portmapping-01 looks to be  
sufficient to allow a server to determine that multiple requests come  
from the same client, provided the client isn't multi-homed and isn't  
sharing an IP address with other clients. The problem statement is not  
clear enough for me to be sure if that's sufficient.

If it were important to do so, the server could distinguish multiple  
clients sharing the same IP address if each client supplied a random  
nonce that was taken into account when generating the token in  
addition to the client's IP address. This may be an issue with use of  
fractional IP addresses in future, and so might be something to  
consider adding.

Distinguishing multi-homed clients, or clients where requests come  
from several different IP addresses, is more complex. Is this an  
issue, or is it sufficient to assume that a client requests a new  
token when changing the address it uses?

I'd also like to note that the port mapping operation is independent  
of the RAMS drafts. It would be good if the draft the group ends up  
with is written as a standalone mechanism, with RAMS described as one  
example use case, rather than being written in a RAMS-specific manner  
as are the current drafts.

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 12 Oct 2010 12:23:05 +0200

Hi Colin,

See below,
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: maandag 11 oktober 2010 18:51
To: Roni Even
Cc: DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing'
Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp

On 8 Oct 2010, at 09:47, Roni Even wrote:
> There were some concerns about how we drafted the consensus call so I 
> would like to try and give it another try.  Sorry for the long message 
> which I hope will clarify what are the proposed options. We would like 
> to get feedback by October 18th.
>
>
> http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast-rtp-02
> previous IETF meetings was to use a cookie based solution even though 
> it required more messages and you needed a cookie for every RTP 
> session.
>
> section on draft-begen-avt-token-for-portmapping). The token draft has 
> Dan Wing (who is also BEHAVE co-chair) as a co-author and he looked at 
> the solution verifying that it will work well with NATs
>
>
> At the meeting the preference was for a token based solution but there 
> are were two approaches discussed.
>
> response will be a token and if it will have both IP address and port 
> the response will be a  cookie.
>
> suggest that they addressed the concerns about the token only solution 
> (see section 9 of the draft) and prefer to have a token only solution. 
> This is a change from the meeting minutes and this is the reason for 
> the second question in this consensus call.
>
> address the response is a token, if it also includes a port it will be 
> a cookie. This approach is for cases were the NAT may use more than 
> one IP address for mapping a local address.
>
>

The approach in draft-begen-avt-token-for-portmapping-01 looks to be sufficient to allow a server to determine that multiple requests come from the same client, provided the client isn't multi-homed and isn't sharing an IP address with other clients. The problem statement is not clear enough for me to be sure if that's sufficient.

If it were important to do so, the server could distinguish multiple clients sharing the same IP address if each client supplied a random nonce that was taken into account when generating the token in addition to the client's IP address. This may be an issue with use of fractional IP addresses in future, and so might be something to consider adding.

TOM: I think this is a good idea. The SSRC of the client associated with the SSM RTP session that is present in the portmapping request message could be used for that purpose (hence token is determined by server on the basis of IP address, time stamp  and client SSRC)

Distinguishing multi-homed clients, or clients where requests come from several different IP addresses, is more complex. Is this an issue, or is it sufficient to assume that a client requests a new token when changing the address it uses?

TOM: IMO that will do..I think it is bad practice if a network stack on a host device/ NAT device allocates different IP addresses towards a application/end-host 

I'd also like to note that the port mapping operation is independent of the RAMS drafts. It would be good if the draft the group ends up with is written as a standalone mechanism, with RAMS described as one example use case, rather than being written in a RAMS-specific manner as are the current drafts.

TOM: The text is meant to be (only) applicable to scenarios building on SSM sessions with unicast feedback, no? We wanted a fast -inband- way for a client to communicate the client receive port for a unicast connection that is linked to such a SSM. In that case, the text is sufficiently generic (e.g. RAMS is not even mentioned in the text, whereas the example is about retransmissions). I take it that any other parameter signaling (port, any attributes,..) for any other scenario needs to leverage the SDP offer-answer model.  

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Oct 2010 07:33:51 -0400

On 12 Oct 2010, at 06:23, Van Caenegem, Tom (Tom) wrote:

>> has
>> solution
>> be
> sufficient to allow a server to determine that multiple requests  
> come from the same client, provided the client isn't multi-homed and  
> isn't sharing an IP address with other clients. The problem  
> statement is not clear enough for me to be sure if that's sufficient.
>
> addition to the client's IP address. This may be an issue with use  
> of fractional IP addresses in future, and so might be something to  
> consider adding.
>
>
> TOM: I think this is a good idea. The SSRC of the client associated  
> with the SSM RTP session that is present in the portmapping request  
> message could be used for that purpose (hence token is determined by  
> server on the basis of IP address, time stamp  and client SSRC)

No, because the SSRC can change, and this should be persistent per  
client.

> TOM: IMO that will do..I think it is bad practice if a network stack  
> on a host device/ NAT device allocates different IP addresses  
> towards a application/end-host
>
> with is written as a standalone mechanism, with RAMS described as  
> one example use case, rather than being written in a RAMS-specific  
> manner as are the current drafts.
>
> TOM: The text is meant to be (only) applicable to scenarios building  
> on SSM sessions with unicast feedback, no? We wanted a fast -inband-  
> way for a client to communicate the client receive port for a  
> unicast connection that is linked to such a SSM. In that case, the  
> text is sufficiently generic (e.g. RAMS is not even mentioned in the  
> text, whereas the example is about retransmissions). I take it that  
> any other parameter signaling (port, any attributes,..) for any  
> other scenario needs to leverage the SDP offer-answer model.
>
> Cheers,
> Colin
>
>
> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>

-- 
Colin Perkins
http://csperkins.org/

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 12 Oct 2010 14:06:54 +0200

Yes, you are right on SSRC. A dedicated random nonce will be required. 
Are you OK with my view on how wide (or narrow) the cookie method can be used?
Tom

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: dinsdag 12 oktober 2010 13:34
To: Van Caenegem, Tom (Tom)
Cc: Roni Even; DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing'
Subject: Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp

On 12 Oct 2010, at 06:23, Van Caenegem, Tom (Tom) wrote:

>> would like to try and give it another try.  Sorry for the long 
>> solution (see section 9 of the draft) and prefer to have a token only 
>> solution.

No, because the SSRC can change, and this should be persistent per client.

> on a host device/ NAT device allocates different IP addresses towards 
> a application/end-host
>
> way for a client to communicate the client receive port for a unicast 
> connection that is linked to such a SSM. In that case, the text is 
> sufficiently generic (e.g. RAMS is not even mentioned in the text, 
> whereas the example is about retransmissions). I take it that any 
> other parameter signaling (port, any attributes,..) for any other 
> scenario needs to leverage the SDP offer-answer model.
>
> Cheers,
> Colin
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>

--
Colin Perkins
http://csperkins.org/