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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 8 Sep 2010 14:36:27 +0200

(As WG cochair)

As part of the RAMs work we have a dependent draft in draft-ietf-avt-ports-for-ucast-mcast-rtp. This provides a cookie based approach to port mapping. See:

https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp/

At IETF#78 we discussed a token based approach, which could be used in some circumstances as an alternative mechanism for solving the problem, and which has less overhead than the cookie based approach. We asked Ali to write this up as a draft so that people could discuss something written down, and he has duly done this as draft-begen-avt-token-for-portmapping-01
available at:

https://datatracker.ietf.org/doc/draft-begen-avt-token-for-portmapping/

This message therefore requests the working group to come to consensus on one of the following two alternatives:

1)	To incorporate material from draft-begen-avt-token-for-portmapping-01 into draft-begen-avt-token-for-portmapping-01 so that the draft describes a combined token / cookie approach.

OR

2)	To proceed with draft-begen-avt-token-for-portmapping-01 with the current technical contents as the solution.

Please reply to this message with your positions. Please feel free to respond with questions for additional clarification if you need that clarification to make a decision. 

Please respond by close of business on Friday 17th September at the latest in order for a WG decision to be made.

This call is not about the final form of the words, so while you are welcome make make proposals in that direction, please keep those to separate threads.

regards

Keith

---

From: <[email-masked]>
Date: Thu, 16 Sep 2010 16:30:00 +0200

We are ok to merge token and cookie draft.

But it could be useful to have
options according to security issues:

1) Possibly nothing, if the
transaction is all inside a very secure network (under the operator's
responsability).

2) about token we would prefer a
slightly modified approach (simpler and more powerful), by
having the token based
on SSRC. When receiving a RTCP FB to request a token (message to
define), the server ascertains the token from the SSRC of packet sender
and the SSRC of the media sender as defined in RFC 4585. Because (1)
the SSRC of packet sender never changes in a session and (2) the token
includes neither the port number nor the IP address, it is fully
compatible with all NAT processing and NAT configuration changes, and a
single exchange at starting the session is enough in all cases. An
additional processing may be (rarely) necessary when two receivers of
the same multicast stream choose a same SSRC packet
sender value.

Regards,

Gerard BABONNEAU,

Xavier MARJOU

Emile STEPHAN

DRAGE, Keith (Keith) a écrit :

(As WG cochair)

OR

regards

Keith
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Thu, 16 Sep 2010 10:58:00 -0400

On Sep 16, 2010, at 10:30 AM, <[email-masked]> wrote:

> But it could be useful to have options according to security issues:
> 1) Possibly nothing, if the transaction is all inside a very secure network (under the operator's responsability).
Sure, if you KNOW that a priori and can convince yourselves that you are immune from mistakes. Usually we write security considerations and/or applicability statements so that things are mandatory to implement but optional to deploy. I would prefer that from a specification point of view, the necessary security methods be mandatory to implement, as the vastly most common deployments are going to be with the clients in unsecured physical locations and on systems that are not particularly difficult to hack.

> 2) about token we would prefer a slightly modified approach (simpler and more powerful), by having the token based on SSRC. When receiving a RTCP FB to request a token (message to define), the server ascertains the token from the SSRC of packet sender and the SSRC of the media sender as defined in RFC 4585. Because (1) the SSRC of packet sender never changes in a session and (2) the token includes neither the port number nor the IP address, it is fully compatible with all NAT processing and NAT configuration changes, and a single exchange at starting the session is enough in all cases. An additional processing may be (rarely) necessary when two receivers of the same multicast stream choose a same SSRC packet sender value.
> 
How would you know if you can rely on this? There is no specification that prohibits the sender from changing their SSRC, only a relaxation of the collision rules in RTCP that removes the requirement that they change it on a collision. It also seems inadvisable to have random values that are constrained to 32 bits - if the token can be 64 bits or larger, collision probability goes essentially to epsilon above zero. 

What's the concern here about a different state variable for the token? Storage?

DaveO.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Sep 2010 17:17:23 +0200

(As WG cochair) 

A reminder that we are looking for input to this question by the end of tomorrow.

Please review and post.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of DRAGE, Keith (Keith)
> Sent: Wednesday, September 08, 2010 1:36 PM
> To: IETF AVT WG
> Subject: [AVT] Consensus call - Token approach within 
> draft-ietf-avt-ports-for-ucast-mcast-rtp
> 
> (As WG cochair)
> 
> As part of the RAMs work we have a dependent draft in 
> draft-ietf-avt-ports-for-ucast-mcast-rtp. This provides a 
> cookie based approach to port mapping. See:
> 
> At IETF#78 we discussed a token based approach, which could 
> be used in some circumstances as an alternative mechanism for 
> solving the problem, and which has less overhead than the 
> cookie based approach. We asked Ali to write this up as a 
> draft so that people could discuss something written down, 
> and he has duly done this as draft-begen-avt-token-for-portmapping-01
> available at:
> 
> This message therefore requests the working group to come to 
> consensus on one of the following two alternatives:
> 
> 1)	To incorporate material from 
> draft-begen-avt-token-for-portmapping-01 into 
> draft-begen-avt-token-for-portmapping-01 so that the draft 
> describes a combined token / cookie approach.
> 
> OR
> 
> 2)	To proceed with 
> draft-begen-avt-token-for-portmapping-01 with the current 
> technical contents as the solution.
> 
> Please reply to this message with your positions. Please feel 
> free to respond with questions for additional clarification 
> if you need that clarification to make a decision. 
> 
> Please respond by close of business on Friday 17th September 
> at the latest in order for a WG decision to be made.
> 
> This call is not about the final form of the words, so while 
> you are welcome make make proposals in that direction, please 
> keep those to separate threads.
> 
> regards
> 
> Keith

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Sep 2010 08:38:34 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, September 16, 2010 10:30 AM
> To: DRAGE, Keith (Keith); IETF AVT WG
> Cc: MARJOU Xavier RD-CORE-LAN; STEPHAN Emile RD-CORE-LAN
> Subject: Re: [AVT] Consensus call - Token approach withindraft-ietf-avt-ports-for-ucast-mcast-rtp
> 
> 2) about token we would prefer a slightly modified approach (simpler and more powerful), by having the token based on
> SSRC. When receiving a RTCP FB to request a token (message to define), the server ascertains the token from the SSRC of
> packet sender and the SSRC of the media sender as defined in RFC 4585. Because (1) the SSRC of packet sender never
> changes in a session and (2) the token includes neither the port number nor the IP address, it is fully compatible with all NAT

How so? When a client is joining a new SSM session, its SSRC may very well collide with other receivers already existing in that session. Relying on SSRC is not possible since SSRC can change any time.

-acbegen

> processing and NAT configuration changes, and a single exchange at starting the session is enough in all cases. An additional
> processing may be (rarely) necessary when two receivers of the same multicast stream choose a same SSRC packet sender
> value.
> 
> 
> Regards,
> 
> Gerard BABONNEAU,
> Xavier MARJOU
> Emile STEPHAN
> 
> 
> 
> 	As part of the RAMs work we have a dependent draft in draft-ietf-avt-ports-for-ucast-mcast-rtp. This provides a
> 	At IETF#78 we discussed a token based approach, which could be used in some circumstances as an alternative
> mechanism for solving the problem, and which has less overhead than the cookie based approach. We asked Ali to write this
> up as a draft so that people could discuss something written down, and he has duly done this as draft-begen-avt-token-for-
> portmapping-01
> 	available at:
> 
> 	1)	To incorporate material from draft-begen-avt-token-for-portmapping-01 into draft-begen-avt-token-for-
> portmapping-01 so that the draft describes a combined token / cookie approach.
> 
> 	OR
> 
> 	Please reply to this message with your positions. Please feel free to respond with questions for additional clarification

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 16 Sep 2010 22:58:16 +0700

Keith Drage [mailto://[email-masked]] writes:

...

> > if you need that clarification to make a decision.

OK.  The above alternatives make no sense to me.  Do you really mean 

1) Incorporate material from draft-begen-avt-token-for-portmapping-01 into
draft-ietf-avt-ports-for-ucast-mcast-rtp

OR 

2) Proceed with draft-ietf-avt-ports-for-ucast-mcast-rtp with the current
technical contents as the solution.

??  Something else?

...

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Sep 2010 18:13:49 +0200

Yes your revision is what I meant.

You are obviously the first one to read it.

Keith 

> From: Glen Zorn [mailto:[email-masked]] 
> Sent: Thursday, September 16, 2010 4:58 PM
> To: DRAGE, Keith (Keith)
> Cc: 'IETF AVT WG'
> Subject: RE: [AVT] Consensus call - Token approach within 
> > > draft-begen-avt-token-for-portmapping-01 so that the 
> draft describes 
> > > a combined token / cookie approach.
> > >
> > > OR
> > >
> > > 2)	To proceed with
> > > Please reply to this message with your positions. Please 
> feel free 
> > > to respond with questions for additional clarification if 
> you need 
> > > that clarification to make a decision.
> 
> 1) Incorporate material from 
> 2) Proceed with draft-ietf-avt-ports-for-ucast-mcast-rtp with 
> the current technical contents as the solution.
> 
> ??  Something else?
> 
> ...
> 
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Sep 2010 09:16:48 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Thursday, September 16, 2010 11:58 AM
> To: 'DRAGE, Keith (Keith)'
> Cc: 'IETF AVT WG'

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.

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Sep 2010 18:31:41 +0200

Formally, whatever the decision, the results of this call will go into the current working group document which is draft-ietf-avt-ports-for-ucast-mcast-rtp. 

> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Thursday, September 16, 2010 5:17 PM
> To: Glen Zorn; DRAGE, Keith (Keith)
> Cc: IETF AVT WG
> Subject: RE: [AVT] Consensus call - Token approach 
> withindraft-ietf-avt-ports-for-ucast-mcast-rtp
> 
> 
> 
> Behalf Of 
> > Glen Zorn
> > Subject: Re: [AVT] Consensus call - Token approach 
> > withindraft-ietf-avt-ports-for-ucast-mcast-rtp
> > 
> > > > Please reply to this message with your positions. 
> Please feel free 
> > > > to respond with questions for additional clarification 
> if you need 
> 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.
> 
> > 2) Proceed with draft-ietf-avt-ports-for-ucast-mcast-rtp with the 
> > current technical contents as the solution.
> > 
> > ??  Something else?
> > 
> > ...
> > 
> >

---

From: Roni Even <[email-masked]>
Date: Thu, 16 Sep 2010 21:53:00 +0200

Hi,
I thought the idea of a token is to establish it early and use it for long
time so the SSRC may not be available at the time or may change
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David R Oran
> To: [email-masked]
> Cc: DRAGE, Keith (Keith); MARJOU Xavier RD-CORE-LAN; IETF AVT WG;
> STEPHAN Emile RD-CORE-LAN
> Subject: Re: [AVT] Consensus call - Token approach within draft-ietf-
> avt-ports-for-ucast-mcast-rtp
> 
> 
> > 1) Possibly nothing, if the transaction is all inside a very secure
> network (under the operator's responsability).
> Sure, if you KNOW that a priori and can convince yourselves that you
> are immune from mistakes. Usually we write security considerations
> and/or applicability statements so that things are mandatory to
> implement but optional to deploy. I would prefer that from a
> specification point of view, the necessary security methods be
> mandatory to implement, as the vastly most common deployments are going
> to be with the clients in unsecured physical locations and on systems
> that are not particularly difficult to hack.
> 
> > 2) about token we would prefer a slightly modified approach (simpler
> and more powerful), by having the token based on SSRC. When receiving a
> RTCP FB to request a token (message to define), the server ascertains
> the token from the SSRC of packet sender and the SSRC of the media
> sender as defined in RFC 4585. Because (1) the SSRC of packet sender
> never changes in a session and (2) the token includes neither the port
> number nor the IP address, it is fully compatible with all NAT
> processing and NAT configuration changes, and a single exchange at
> starting the session is enough in all cases. An additional processing
> may be (rarely) necessary when two receivers of the same multicast
> stream choose a same SSRC packet sender value.
> >
> How would you know if you can rely on this? There is no specification
> that prohibits the sender from changing their SSRC, only a relaxation
> of the collision rules in RTCP that removes the requirement that they
> change it on a collision. It also seems inadvisable to have random
> values that are constrained to 32 bits - if the token can be 64 bits or
> larger, collision probability goes essentially to epsilon above zero.
> 
> >> As part of the RAMs work we have a dependent draft in draft-ietf-
> avt-ports-for-ucast-mcast-rtp. This provides a cookie based approach to
> port mapping. See:
> >>
> >>
> >> At IETF#78 we discussed a token based approach, which could be used
> in some circumstances as an alternative mechanism for solving the
> problem, and which has less overhead than the cookie based approach. We
> asked Ali to write this up as a draft so that people could discuss
> something written down, and he has duly done this as draft-begen-avt-
> token-for-portmapping-01
> >> available at:
> >>
> >>
> >> 1)	To incorporate material from draft-begen-avt-token-for-
> portmapping-01 into draft-begen-avt-token-for-portmapping-01 so that
> the draft describes a combined token / cookie approach.
> >>
> >> OR
> >>
> >> 2)	To proceed with draft-begen-avt-token-for-portmapping-01 with the
> >> Please reply to this message with your positions. Please feel free
> to respond with questions for additional clarification if you need that
> clarification to make a decision.
> >>
> >> Please respond by close of business on Friday 17th September at the
> latest in order for a WG decision to be made.
> >>
> >> This call is not about the final form of the words, so while you are
> welcome make make proposals in that direction, please keep those to
> separate threads.
> >>
> >> regards
> >>
> >> Keith
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 5455 (20100916) __________
> 
> The message was checked by ESET NOD32 Antivirus.
> 
> http://www.eset.com
>

---

From: Roni Even <[email-masked]>
Date: Thu, 16 Sep 2010 21:58:44 +0200

Hi,
My opinion is that we should use the token solution based on  Ali's token
draft. It should be the starting point for the next version of
draft-ietf-avt-ports-for-ucast-mcast-rtp.
I am OK with the explanation from Dan Wong about eth consistency of the IP
address over time when going though NAT and the draft should mention the
issue service provider NATs as discussed at the last meeting.
Roni Even
As individual

> DRAGE, Keith (Keith)
> Sent: Thursday, September 16, 2010 6:32 PM
> To: Ali C. Begen (abegen); Glen Zorn
> Cc: IETF AVT WG
> Formally, whatever the decision, the results of this call will go into
> the current working group document which is draft-ietf-avt-ports-for-
> ucast-mcast-rtp.
>

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 17 Sep 2010 12:50:00 +0700

...

> > then we finish the Cookie draft.

OK, but neither of these map to either the alternatives proposed in the
original question nor to the alternatives as rewritten by myself.  Just from
a process POV, I think that it's inappropriate to make any decision at this
time because it seems painfully clear that the question is painfully
unclear. 

...

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 17 Sep 2010 13:18:10 +0700

Ali C. Begen (abegen) [mailto://[email-masked]] writes:

...

> 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.
> 

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...

...

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Sep 2010 23:44:08 -0700

> Sent: Friday, September 17, 2010 2: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
> 

I am afraid you are missing the main point (maybe you were not following the discussion from the beginning). The WG saw the necessity for a solution to address the port mapping problem (discovered during the RAMS discussion). Currently, RAMS is about to conclude its IETF LC and we need to decide and move quickly about this issue so that we won't delay the RAMS any further. Neither the cookie nor the token draft has come up after a 5-min discussion. Several people have been working on this and discussing the possible solutions since Stockholm. 

The cookie approach was the first one we agreed to. But, this draft is being watched by several other organizations who will eventually have a similar problem. They raised some concerns. Here at the IETF, we can either ignore such concerns and do whatever we decided in the first place or listen to them and look for a better approach that can satisfy our requirements and address their concerns. Token draft attempts to do that.

I also don't agree with the statement that the cookie approach is not good enough. It is a good solution but we also need to make sure people will use it. Ow, it is not worth much. Based on my personal knowledge and what I heard from others, the token approach is more welcome by pretty much everybody doing implementation.

The important thing is we make a call here and move forward. I am sure the ADs and co-chairs will let us know the formalities about revising the draft.

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 17 Sep 2010 11:30:31 +0200

These are the notes from IETF#78 concerning this subject in Maastrict. I hope they make things clearer.

regards

Keith

Port Mapping Between Unicast and Multicast RTP Sessions
-------------------------------------------------------

Ali Begen presenting.

[Slide pack avt-10.pdf]

draft-ietf-avt-ports-for-ucast-mcast-rtp-02

- This was split out of RAMS, it's a normative reference for it, needs to go forward quickly

- there are multiple approaches. Had a breakout in Anaheim and some issues came up.

- now there is the WG current draft, an alternative approach, and a third draft as well to consider.

- see Ali's slides for problem description and solution based on cookies

Open issues discussion:

- Which keep-alive method should we choose?

Answer: Guidelines for keepalive usage are already with IESG, use them (draft-ietf-avt-app-rtp-keepalive).

- Should we stick with 4585 packet format for cookie request and response? (Yes) How do we set the media sender SSRC? Use client's SSRC in both packet sender and media sender SSRC fields.

Ali: Currently documented in draft and same as already specified in RAMS.

- Should the client use the same SSRC/CNAME in both sessions so the reports received in two sessions can be linked? (Yes)

Colin: If you use the same SSRC, then they become one RTP session and you have no issue. Need to be careful with the terminology. If a single RTP session be sure to say that.

- Should the server respond if a cookie request is rejected? (Yes, with an empty Cookie).

No comment from working group.

- Should the server indicate the expiration date for the Cookie explicitly in the response message? (Yes)

Jonathan Lennox: How is time specified for expiration? Are you assuming it uses some notion of current time.

Ali: No. Relative time from now. You should refresh your cookie well before the timeout.

Token-based Port Mapping (Ali Begen):

[Slide pack avt-11.pdf]

draft-begen-avt-token-for-portmapping-00

- alternative to cookie approach. Prior solution was to get cookie in advance, but still some people are unhappy; there is overhead.

- see Ali's slides for problem description and solution.

Bill ver Steeg: Even though I'm a co-author on the cookie draft, likes the token approach better.

Token retrieval is done once, based on your IP; valid until the server decides it's invalid. Need only one token no matter how many unicast sessions you want.

Colin Perkins: The token validates your public IP address?  What happens if your NAT gives you multiple IP addresses (i.e. what about Carrier grade NATs?)

Bill Ver Steeg: Carrier Grade NAT is typically between the service-provider's network and the public Internet, whereas this device is typically in the
 
service-provider's network.  If that's not true we should fall back to cookies
.

Colin: if you document those restrictions/assumption then you're ok

Roni: if token is invalid you might send back a different one.

Dave: I'm going to argue both sides of the issue.  One the one side, it's ugly to have solutions that make topological assumptiions.  On the other hand, anything that breaks carrier-grade NATs I'm in favor of.

Ali: we need to decide whether token has better tradeoffs than cookie, who needs lots of cookies, trimers, refreshes, etc.

Jonathan Lennox: if you're the service provider and deploying servers, you have good topological notion but is it really true that you're behind the Carrier Grade NAT?

Colin: It might be possible to unify the solutions; i.e. make the port optional in the cookies, if it's not present it applies to all ports. Combining them is probably not more complicated than either one individually.

Ali: Consensus seems to be do the union.

Colin: Tastier cookies!

Roni: Do we mean that the response has either token or cookie

Colin: token+port=cookie

Jonathan Lennox: In SDP do you have some notion. 
Jonathan Lennox: What is the grouping/correlation? 

Ali: All that share token. 

Jonathan Lennox: As a client how do I know if an existing token will work with a different server? Do we need an "issuer id"? Is there some way to identify whether two sessions are using the same token?

Bill (Eventually): We could add that, we need to think about it

Colin: There's nothing RAMS-specific about this; you can write the
draft in a simpler way if you don't talk in those terms.

Ports on client and server: server ports must be different (to prevent RTCP ambiguity). 

Roni: Tradeoff with token is that it can be rejected if you send token to the same place.

Colin: In SDP put something in - by the way: nothing in here is RAMS-specific
.

Roni: General to multicast/unicast.

Colin: The solution is actually completely general - request a cookie/  then use a cookie. Can write the draft in a simpler way if you don't' tie it to RAMS, or even multicast/unicast use cases.

Jonathan Lennox: On SDP need to be careful about per m= version session-wide. Portmapping-req attitribute: must be at media level, not session.

Colin: Why not?

Jonathan: It would have to apply to every m= line.  It clearly doesn't make sense in this case (because you can't have a feedback target for the multicast group) but you can imagine cases where multiple m= lines all have the same token server.

Chairs: Hearing that WG support for a combination approach. See on list if this should replace the current WG draft, then write it up if people agree.

Jonathan Lennox: Some discomfort on the topological restriction issue.

Chairs: Proposed procedure - update the individual draft (and achieve consensus on that) then consensus call to whether to replaced the WG draft with the combined proposal in the individual draft. This approach got WG support.

> Sent: Friday, September 17, 2010 6:50 AM
> To: DRAGE, Keith (Keith); 'Ali C. Begen (abegen)'
> Cc: 'IETF AVT WG'
> > > 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.
> 
> OK, but neither of these map to either the alternatives 
> proposed in the original question nor to the alternatives as 
> rewritten by myself.  Just from a process POV, I think that 
> it's inappropriate to make any decision at this time because 
> it seems painfully clear that the question is painfully unclear. 
> 
> ...
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 17 Sep 2010 16:05:01 +0200

Hi,

I do support the development of a token based solution. However, it
should be clear that it most likely will result in something that has
limited applicability. I think that is a bit unfortunate.

As I see it a cookie exchange for each session that is to be generated
gives best possible security against traffic hijacking or usage as DoS
tool. The token approach do have some vulnerabilities. On the plus side
is the gain of one RTT before media can flow. I think we can consider
further mitigation methods to improve this without fundamental impact.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 19 Sep 2010 15:36:44 +0700

> hope they make things clearer.

Not really ;-).  My concerns have little to do with either the technical
content of the drafts or the events that took place during the Maastrict
sessions.  My point is that the consensus call was indecipherable by an
ordinary human; in order to understand it, one would need to already know
what it meant (since merely reading it didn't help).  So what I'm asking is
that another call be issued, this one very clear.  

...