Subject: [AVT] My comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00

From: Magnus Westerlund <[email-masked]>
Date: Sun, 28 Feb 2010 22:55:43 +0100

Hi,

Here are my comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-00.

1.Section 1, paragraph 1:

I think you need to clarify why it doesn't matter that the client choses
ports in multicast, i.e. that the port ranges are on a per address basis.

2. Section 1, paragraph 2: I would remove "often". Based on the issues a
client will always need to do this. I am also missing some mention of
the reasons why this is. I think it is worth listing the motivation as
it seems to escape some people.

3. Section 1, paragraph 5: I would suggest not to use "retransmission"
in the RAMS context, rather talk about rapid aquistion bursts or
something to separate the usages of this unicast traffic.

4. Section 3:    o  Do not introduce new vectors for attacks.

I think this is highly desirable, but not really possible. I would add
to the sentence "that aren't mitigated."

5. Section 3:
   o  Do not have any IPv4/IPv6 dependencies.  To the extent that
      addressing information is required to persist across transactions,
      handle the addresses in a manner that allows the server to give
      opaque address information (called Cookie) to the client.  The
      client then presents the opaque addressing information back to the
      server in subsequent transactions.  This allows the system to
      maintain connectivity information without unduly burdening the
      server(s) with state information.

I find this text a bit strange. I agree with the sentiment of trying to
avoid having address specific information. However, if it is needed,
then it rather needs to handle the different familes and be extensible
for additional address formats. I would like to point out that RTP is
not mandated to be run over IP at all. Thus if address information is
needed it needs to be identified and have support for varying size both
between families and within families.

6. Section 3: I am missing a firewall goal. Here one needs to be clear
that firewall might be setup to prevent these flows as at all which
shouldn't be circumvented. However, for simple firewalls rules that
block incomming traffic flows but not bi-directional flows that has been
initiated from the inside. In regards to the NAT cases where port and
address translation is happening this provides different requirements.
Although a solution that handles NAPT will most likely solve this use
case also. But firewalls will continue to exist also in IPv6 networks
even if NAPTs are not present anymore.

7. Figure 2:

a. The port identifier P2 is used twice in different contexts.
b. I think there is a point to prefix the multicast ports with the
address, for example MA:P1 and MA:P2 while the RS right side P2, P3 and
P4 to my understanding are all unicast address ports, which could be
indicated as UA:P3.
c. The question is if we need to know the external ports on the NAT side
in the discussion and that these should be explicitly labeled also.

8. Section 4:

I think the description of the scenario depecited in figure 2 needs a
bit more detail, like talking about the needed flows to realize this
scenario.

9. Section 4.1:
Actually I think starting with the SDP is the wrong ended. I would start
with a high level overview of how the solution creates the necessary
flows and what they are. As I see it parts of the SDP here is what needs
to be specified by this document. For example that the RS side source
ports and address for the retransmission unicast session and its media
configuration are expressed as particular labeled and grouped own media
stream, separate from the feedback target address for the multicast.

10. Section 4.1: So I think most of the text below the SDP should be
moved up to describe figure 2 minus the SDP and the explicit ports and
address and rather use symbolic labels.

11. Section 4.2:

I am missing an overview description of the solution. What is the main
point of it?

12. Section 4.2.1, step 3: I think the client really should include a
client cookie in its request messages that is echoed back in the servers
response in step 6. The reason for this is to ensure that there is no
mixup between requests and responses. It would also protect against an
attacker inserting response towards the client based on previous
requests. Prevents off path attacker to insert bogus responses to the
client.

13. Section 4.2.1, step 6: I personally think sending the answers to the
RTP portmapping response back in the RTCP return channel is a bad idea.
This as it doesn't test the return routability of that specific port. It
is important that the reverse path is checked for each port. Now you can
have the RTCP RS to client path work but not the RTP one. If you send
response symmetrically then the client will know that the path works
prior to sending a retransmission request.

14. Section 4.2.1, step 8: What is when necessary. I think you need to
specify if this needs to be in all future RTCP request messages, or if
the server will do a binding between the RTCP request 5-tuple and the
included cookie and hold on to that for a while.

15. Section 4.2.1, step 9: What about keep alive for the RS to client
RTP flow to c2? To keep that flow open the client will need to send
occational traffic from client to RS.

16. Section 4.2.1, step 5: I think this should be clarified to
encapsulate the full 5 tuple, i.e. source and destination address and
port plus protocol as seen by the server for the port mapping request.
The cookie should probably also contain some server side timestamps to
prevent playback attacks.

17. Section 4.2.2: If there are no NAT devices between the server and
client, the client
   MUST acquire a cookie for each distinct 2-tuple of (S, c2) and (S,
   c3).

I think this should be the 5-tuple. It is important that the same local
address is used and also the same server port and over the right
protocol. Hosts with weak addressing models could get in to trouble here.

18. Section 4.2.2, second paragraph. As the NATs behavior may be varying
over time, relying on a NAT to keep being endpoint independent mapping
is not recommended at all. There is also the filtering rules of the
firewall that commonly are endpoint dependent. Thus designing for the
strictest case is the simplest and requires least amount issues.

19. Section 4.2.2:
   When the client is behind a NAT, it needs to send periodic packets to
   keep the NAT bindings alive [RFC4787].  If the NAT device fails for
   some reason and then restarts, the public IP address and ports
   assigned to a client may change.  This will invalidate the previously
   acquired cookies.  Upon detecting the failure, the client must
   acquire new cookies.

The issue is how the client determine that the mapping has changed prior
to a failure. After all determining that the mapping is the problem when
issuing a NACK request and not getting a response is not certain. The
packet loss can have happened both on request leg and the retransmission
leg for other reasons then that the mapping has gone down.

As I see the way of providing that information to the client would be to
have the address and port as seen by the server be explicitly
communicated in the response messages. That way it can be detected if it
has changed. This as the server side mapping response cookie will likely
look different for each request if a server side timestamp is included.

20. Section 4.3:

This method is broken from a security stand point. There are no server
to client back the server containing a server selected secret. So this
method allows an attacker that isn't behind a NAT to send the mapping
requests with spoofed source addresses. Then it can use the cookie in a
RAMS burst request to generate a large amount of traffic towards its
intended target. In other word this is a nice little DoS attack tool
that only is mitigated by source address filtering. Something that isn't
deployed for more than a quarter of the total used unicast addresses.

This is mitigated in the server side cookie mechanism by the having the
server side cookie be hashed using a server secret key. The client
requesting RAMS service needs to get the response from the server with
this cookie and include it in its RAMS burst request. The only weakness
in this method is the timing aspects. That is why I think the server
needs to include a timestamp and only allow cookies that aren't to old.

Thus I think this solution draft should skip the client side cookie
mechanism and only specify the server side cookie mechanism.

21. To check the intentions here, to specify how to use this mechanism
with NACK. Do you intend to write a short separate draft for that use
case? The reason I am asking is the question on how one binds the mapped
sessions to the request in RTCP. As a separate RTCP packet part of an
compound packet? Or as a more integrated part of the different requests?
For RAMS the later can clearly be specified as this is just one more TLV
in that solution. But for NACK that is not possible. So what are the
thoughts there?

22. I think not mandating the use RTP and RTCP MUX for these
applications only increases the complexity without any gain. Having
separate flows for RTP and RTCP when both sides anyway need to be able
to demux RTP from binding requests/responses does not make a lot of
sense. Do you have a use case where you think the muxing has bad impact
on the solution and where the time separation for demultiplexing is
sufficient and that other solutions can be used for client to server
keep alive over the RTP flow?

23. The draft needs a section on cookie construction, one for the
client, which can be truly opaque as the client can have table binding
local port and destination information to a random number. However the
server cookie seems to have need for some client readable information
about the 5-tuple plus a opaque part that will contain a server side
secret key used to hash some of this information to ensure that clients
can't tamper with it.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 28 Feb 2010 17:37:40 -0800

Hi Magnus,

My responses are inline.

> ports in multicast, i.e. that the port ranges are on a per address basis.

OK.
 
> it seems to escape some people.

I am hoping we will have a better abstract/intro in later versions.
 
> something to separate the usages of this unicast traffic.

Good idea.
 
> to the sentence "that aren't mitigated."

Sure.

> between families and within families.

Fair enough, but I believe that subsection will be removed once we agree on a solution. Even if we keep it, we can revise it accordingly.
 
> 6. Section 3: I am missing a firewall goal. Here one needs to be clear

Would you specify the firewall goal you have in mind? We will be glad to add it.

> a. The port identifier P2 is used twice in different contexts.

That is intentional, which port could we use else?

> in the discussion and that these should be explicitly labeled also.

I partly agree as introduction of external ports really complicates the diagrams. I can use prime's if you like such as c2' and c3'. That might help.

But, the main discussion is for the scenario where there is no NAT. If readers can understand that scenario well, the extended scenario with NAT is pretty straightforward.
 
> bit more detail, like talking about the needed flows to realize this

OK.
 
> address and rather use symbolic labels.

Starting with an SDP and explaining things on it was easier for me (to contemplate the concepts and explain them), but we can do the otherwise.

> I am missing an overview description of the solution. What is the main

Steps in 4.2.1 are not clear?
 
> requests. Prevents off path attacker to insert bogus responses to the

Yeah, this is like a hybrid approach Tom was discussing earlier. We might consider that option.

> prior to sending a retransmission request.

What does "sending response symmetrically" mean here? I wanna make sure I understand it right.
 
> included cookie and hold on to that for a while.

Good point. I believe both cookies (if client is not port muxing) need to be included in the RTCP message that establishes the unicast sessions (nack, rams-r, etc.) Then, the server needs to remember client's ports until the session is ended anyway.

> occational traffic from client to RS.

Yes. In any approach, both ports need to be kept alive.

> prevent playback attacks.

I believe the draft should define (maybe recommend, too) one way of generating cookies (timestamp is a good idea). 
 
> protocol. Hosts with weak addressing models could get in to trouble here.

I am fine with protocol, but including local server ports may not be a good idea. It limits the usability of the cookie, meaning that in RAMS context for example, the client will have to acquire a different cookie for every FT running on the same server (which could be 100s or 1000s). Oppositely, if the same cookie can be used for every FT, this greatly reduces the cookie-acquisition delay or RAMS delay.

> strictest case is the simplest and requires least amount issues.

I agree but if there are certain optimization a client can do, why not benefit from them? We can be conservative and assume the worst, or we can be optimistic and switch to the worst case if better alternatives do not work.

This should be discussed in the WG.
 
> leg for other reasons then that the mapping has gone down.

Failure detection by the client is problematic and may take time.
 
> look different for each request if a server side timestamp is included.

Are you suggesting the server should send a cookie failure message when the cookie fails? The server can do that but that might be an invitation to attackers, no?
 
> requests with spoofed source addresses. Then it can use the cookie in a

Are we supposed to deal with spoofed source address attacks? Those could be an issue for anything if the network does not deal with them (just consider a regular nack without the complication of cookie). 

> this cookie and include it in its RAMS burst request. The only weakness

Right.

> needs to include a timestamp and only allow cookies that aren't to old.

Why can't a client use a cookie it acquired say 24 hours ago? Why would the cookie expire? The client should be able to use it as long as its public address/ports have not changed. 

> mechanism and only specify the server side cookie mechanism.

OK. But we need to be flexible about cookie expiration.

> in that solution. But for NACK that is not possible. So what are the

My personal opinion is that we define a new RTCP message format and that format is sent in the same compound packet with NACK. If they go in separate packets, it is no good.

> applications only increases the complexity without any gain. Having

That is one more vote for muxing!

> keep alive over the RTP flow?

Not really. My initial concern was that some applications (in particularly older ones or the ones that have limited applicability) do not support port muxing. But, port muxing greatly simplifies the design here and since applications need to be modified to support port mapping, they can also be modified to support port muxing. I expect the total amount of new code will be less with muxing enabled.

> secret key used to hash some of this information to ensure that clients

Agree, we should include a section on cookie generation. It might be the recommended way, or the mandated way, but at least should give an idea how the cookie is encoded.

Thanks for the detailed review.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Mar 2010 03:46:45 +0100

Hi

Removing the things where there isn't more to discuss or comment.

> That is intentional, which port could we use else?

Well, the P2 on the left side is the RTCP port in the multicast address.
While P2 on the right side of the RS is the feedback target address for
RTCP. They are clearly two different addresses even if they are related.
Thus unless your prefix them I find it confusing.

> But, the main discussion is for the scenario where there is no NAT. If readers can understand that scenario well, the extended scenario with NAT is pretty straightforward.

I think this will require some work, but it might be simpler to have two
different figures so that you only add the NAT when you come to that
discussion.

> Starting with an SDP and explaining things on it was easier for me (to contemplate the concepts and explain them), but we can do the otherwise.

As I said, part of the SDP will however need to be defined in this
document, but I did get want you wanted for this initial discussion.
However, I think in future version this will need to change.

> Steps in 4.2.1 are not clear?

The steps in 4.2.1 is reasonably clear. But first providing the 10000
feet picture before producing the 1000 feet one can help the reader
understand the 1000 feet picture much better.

> Yeah, this is like a hybrid approach Tom was discussing earlier. We might consider that option.

I see the client cookie as protection mechanism against strange
behaviors and configuration mistakes and also provide some security
protection.

> What does "sending response symmetrically" mean here? I wanna make sure I understand it right.

That the RTCP port mapping response is sent with a destination address
and port that is equal to the source address and port of the request and
with a source address and port that is equal to the destination address
and port of the request. What I understand of the current solution the
response to the RTP port request is sent back over the RTCP port. Thus
never testing the return path from the RTP port.

> Good point. I believe both cookies (if client is not port muxing) need to be included in the RTCP message that establishes the unicast sessions (nack, rams-r, etc.) Then, the server needs to rememb…

I think there is arguments both way here. However for retransmissions
where the frequency of NACK requests can be reasonably high I think
performing that server side binding will be a better solution. However,
both the reliability question and the update will need to be taken into
account.

> Yes. In any approach, both ports need to be kept alive.

I forgot to ask which mechanism you forsee using here, RTCP port mapping
requests or something else?

> I believe the draft should define (maybe recommend, too) one way of generating cookies (timestamp is a good idea).

Agreed, certain aspects of the cookies likely need to be defined. While
I think the actual hashing and how big the opaque part is can be left to
implementations.

> I am fine with protocol, but including local server ports may not be a good idea. It limits the usability of the cookie, meaning that in RAMS context for example, the client will have to acquire a…

I think this is something that will need to be discussed. However,
different RTP unicast target address + port on the RS will require
different port mapping requests. Then there is a question if you can
re-use that unicast session accross multiple multicast RTP sessions? I
think that needs further investigation. However, to avoid the DoS angle
you will need current and valid cookies for each new path between the
client and server.

> I agree but if there are certain optimization a client can do, why not benefit from them? We can be conservative and assume the worst, or we can be optimistic and switch to the worst case if better…

The first part is that it creates implementation complexities that
likely are not motivated.

When you take the filtering behavior and the DoS angle into account and
you anyway need to send client to server traffic and have a server to
client verification path then I don't see any gain, only complexities.

> This should be discussed in the WG.

Yes.

> Failure detection by the client is problematic and may take time.

My idea here is to at least consider that the keep-alive mechanism will
be able to detect that a mapping change has happened, thus requiring the
client to update the unicast session mapping. So rather then to invent
any new mechanism simple ensure that the ones needed anyway will do the
jobb.

> Are you suggesting the server should send a cookie failure message when the cookie fails? The server can do that but that might be an invitation to attackers, no?

My idea is to simple have the client update its binding using the latest
and current cookie when it has detected that there was a mapping
timeout/Failure resulting in a new externally seen 5-tuple.

> Are we supposed to deal with spoofed source address attacks? Those could be an issue for anything if the network does not deal with them (just consider a regular nack without the complication of co…

Yes, I think this is required to be handled. RAMS especially is such an
efficient mechanism for these attacks. That is why the server needs to
know that the target address and port really do wish to receive media.
That is accomplished by having the server generated cookie be sent on a
response going back to where the mapping request appears to come from to
the client. If the client can receive it and then give it to the server
that is proof that the given address is really wanting the media and are
not a target.

Note, to fool the above check the attacker need to be on the path of the
media, thus having to cope with the DoS traffic also. Which is not 100%
water tight but a reasonably strong mitigation.

> Why can't a client use a cookie it acquired say 24 hours ago? Why would the cookie expire? The client should be able to use it as long as its public address/ports have not changed.

And how does the server or the client know that the external address of
the client hasn't changed? A NAT with multiple hosts inside it can
clearly have the issue that one binding times out and is replaced by a
binding own by another host. Thus the cookie shouldn't be valid for much
longer than what can be expected that the binding is valid. There is a
trade off here, between the load for generating new cookies and updating
the unicast session binding with new cookies. I think that will need
some analysis.

The second angle is the replay attack you can do if the cookie doesn't
expire. If you at some point manage to snoop the cookie from a
transaction between the target and an RS, then an attacker could resuse
that cookie for periodic new rams request to a client that is no longer
interested in rams requests.

These are the two reasons I see that the cookie should expire. I think a
lifetime of no more than 60 min seems appropriate here. Although this is
just my initial guess.

> OK. But we need to be flexible about cookie expiration.

Maybe, lets analyse this a bit more.

> My personal opinion is that we define a new RTCP message format and that format is sent in the same compound packet with NACK. If they go in separate packets, it is no good.

Agreed, I think this is the appropriate to include them in a compound. I
was more thinking if you want to make the requirement even stricter, but
I think binding across a compound message will work.

> Not really. My initial concern was that some applications (in particularly older ones or the ones that have limited applicability) do not support port muxing. But, port muxing greatly simplifies th…

Yes, I share this analysis of the situation.

> Agree, we should include a section on cookie generation. It might be the recommended way, or the mandated way, but at least should give an idea how the cookie is encoded.

Damm, responding to this message ate some of the time I had to review
the RAMS doc. Lets see if I still can managed to complete this before
the day ends, not certain.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 28 Feb 2010 19:18:33 -0800

> > Would you specify the firewall goal you have in mind? We will be glad to add it.

Forget to mention something here?
 
> Thus unless your prefix them I find it confusing.

But at the end they are the same port. 

The 'a=rtcp:41001 IN IP4 192.0.2.1' line in the SDP specifies the RTCP port of the feedback target. That is also the port where RTCP of the primary session is multicast to.

OK. 

> never testing the return path from the RTP port.

Right, but that is the only way if client is not port muxing. If it is port muxing, this won't be an issue.

> requests or something else?

There is a draft for rtp keepalive. 
http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-07.html 

we should probably pick the best one and mandate it?

> I think the actual hashing and how big the opaque part is can be left to

Yup.
 
> > I am fine with protocol, but including local server ports may not be a good idea. It limits the
> usability of the cookie, meaning that in RAMS context for example, the client will have to acquire a
> different cookie for every FT running on the same server (which could be 100s or 1000s). Oppositely,
> if the same cookie can be used for every FT, this greatly reduces the cookie-acquisition delay or RAMS
> delay.
> 

Only if you use a 2/3-tuple instead of 4/5-tuple.

> > I agree but if there are certain optimization a client can do, why not benefit from them? We can be
> conservative and assume the worst, or we can be optimistic and switch to the worst case if better
> alternatives do not work.
> 

I guess I agree.
  
> > Why can't a client use a cookie it acquired say 24 hours ago? Why would the cookie expire? The
> client should be able to use it as long as its public address/ports have not changed.
> 

The client might keep such bindings alive.

> the unicast session binding with new cookies. I think that will need

Fair enough.
 
> lifetime of no more than 60 min seems appropriate here. Although this is

Coming up with a magical number is difficult here. We either allow the cookies to be used as long as the bindings are still valid, or require the client to acquire a new port mapping cookie every time there is a need (very short-duration cookies). I am inclined towards the former.

> > Agree, we should include a section on cookie generation. It might be the recommended way, or the
> mandated way, but at least should give an idea how the cookie is encoded.
> >
> 

We really wanna finish the RAMS draft by the March meeting so that other SDOs may have a solid reference.

Thanks,
-acbegen