Subject: RE: [MMUSIC] Peer-to-peer STUN in ICE

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Sep 2004 12:59:25 -0700

> > ICE makes this problem better by making sure further packets are
> > sent only if there is a STUN response. As such, ICE only improves 
> > upon the situation.
>
> I think the difference is that if you were completely dumb about the
> possible use of private addresses you would end up sending the SIP
> signalling to C rather than B in the first place. 

You were discussing ICE, which only attempts to work with RTP.  But
now you're talking about using ICE to change where SIP signaling is
sent?  ICE doesn't do that today.

> 5060 turns out to be
> quite a good port to send to for the purposes of avoiding hitting
> ports doing other things. With TCP (SIP, H.323, FTP etc), attempting
> to initiate a TCP connection to a TCP socket that is a client (and not
> listening) would also fail beneignly. Hence you wouldn't get the
> problem. It's the cut-through issue that ICE offers that introduces
> the new way of working.

-d

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

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 22 Sep 2004 22:07:55 +0100

From: "Dan Wing" <[email-masked]>

>From the part of the sentence that says "...if you were completely dumb
about the possible use of private addresses..." implies among other things
that you are NOT running ICE which is designed to tackle the issue of
private addresses and the problems they introduce (i.e. NATs, overlapping
address spaces and so on)  in the scenario just mentioned.  Hence I am not
suggesting ICE with SIP signalling.

The statement was that ICE makes the impact of an unintended DoS on an
innocent third-party host C better.  I'm not sure it does.  We have to
consider the whole system, the clients A and B in different realms trying to
communication and the various proxies.

If the whole system is NAT unaware, and A and B are in different realms, A
and B will never be able to contact each other for the initial SIP
communication.  If nothing else, a global proxy will not be able to address
B.  (If B is global, B will not be able to send to the private addresses
declared by A.  A will be able to send to B, but packets are not
unintentionally sent to any third party.)

An alternative system can then be NAT aware to the level of being able to
get the signalling through NATs (rport, persistent TCP register connections
etc.).  In this case, where the system does not take any measures to get the
RTP through the NATs, then yes, ICE will mean that C is subjected to less
unintended DoS traffic.  But deploying a system that knows about NATs such
that the signalling can pass, but doesn't do anything about the RTP is
surely not a sensible route for the IETF!

A final system knows about NAT for both signalling and RTP.  One would hope
that under these conditions in a properly designed system C is not exposed
to an unintended DoS.

So ICE helps in the dysfunctional system only!

I'll try and explain the problem one more time.  You have to remember that
SIP and RTP are not the only protocols that run over the Internet!

Host A is running a SIP UA.  It is in Realm R1 and uses private address A,
port a for its RTP.  To uniquely identify this address let's use the
notation R1(A):a (note that this can not be expressed directly in any single
IP address).

Host B is also running a SIP UA.  It is in Realm R2 and uses private address
B, port b for its RTP.  With the above notation, the global address is
R2(B):b.

Host C is in realm R1.  It is running TFTP or some other UDP client or
server such that the port has been assigned from the dynamic range that RTP
ports are assigned.  As it turns out, C is running the UDP protocol on
address B, port b, with resultant notation R1(B):b.

That's the system setup.  The call sequence proceeds as follows:

A, by what ever means sends an INVITE to B.  Both are NAT aware and ICE
aware.

As part of the ICE info, B tells A to send RTP (i.e. STUN initially) to
private address B(b).

A then attempts to send STUN requests to B(b).  However, this ends up at
R1(B):b, unintentionally DoSing C's TFTP session (or whatever).

In summary, if you know nothing about NAT, calls fail, but nobody gets
hurts.  If you do a partial solution for NATs, innocent parties get
unintentionally DoSed.  I don't think the IETF should be accepting this
colatoral damage.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Sep 2004 17:40:28 -0400

> So ICE helps in the dysfunctional system only!

[snip]

> unintentionally DoSed.  I don't think the IETF should be accepting this

Isn't the point to specify what a "properly designed system" should do?
ICE is being proposed as part of that. So I guess you are suggesting 
that ICE is the wrong solution.

Do you have a better one in mind - that works with existing NATs and 
doesn't have the problems you are pointing out?

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 22 Sep 2004 14:50:51 -0700

Pete Cordell wrote:

...
> That's the system setup.

Okay.

> The call sequence proceeds as follows:
>

I agree that C will receive one, or more, STUN packets.  I agree that
the STUN packet could interfere with whatever application C is running.

I believe I understand your argument to this point.  It's after this
point in the email that I don't understand the problem you're describing.

> unintentionally DoSed. I don't think the IETF should be accepting this

I just re-read your original post (with your correction) at
http://www1.ietf.org/mail-archive/web/mmusic/current/msg02886.html
and I believe what you're proposing is an enhancement to ICE so
that if two hosts determine they are in different address realms
that they avoid using the 'local' address realm (because they know
it won't work).  Is that correct?

If that's correct, let's flesh out how we could determine that
we're in different address realms.  One situation that I worry
about, though, is this one, which would via many tests tell you
"you are in different address 'realms'".  In the diagram below,
you can imagine Client A and Client B are connected to the Internet
and the STUN server is somewhere in the Internet.  Figure 1:

       +-------------+
       | STUN Server |
       +--+-------+--+
         /         \
        /           \
       /             \
   +--+--+         +--+--+
   | NAT |         | NAT |
   +--+--+         +--+--+
      |               |
  +---+----+      +---+----+
  |Client A|      |Client B|
  +--------+      +--------+

However, the problem is many tests wouldn't allow us to use the private
network that really exists between Client A and Client B, like this, Figure
2:

         +-------------+
         | STUN Server |
         +--+-------+--+
           /         \
          /           \
         /             \
     +--+--+         +--+--+
     | NAT |         | NAT |
     +--+--+         +--+--+
        |               |
    +---+----+      +---+----+
    |Client A|      |Client B|
    +---+----+      +---+----+
        |               |
        |  +--------+   |
        +--+ Router +---+
           +--------+

where Client A and Client B are really two Enterprise branch offices, both
connected to the Internet, and which also have a network that connects them.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Sep 2004 02:23:44 -0400

inline.

> communication and the various proxies.

I don't think anything about the attack I am describing changes when one 
"considers the whole system".

> communication. 

Well, that's interesting. Another way to look at it is, if I have a 
protocol that is totally broken, so no one can send a message to anyone 
else, that system is "better" since another system that allows 
communication might end up inadvertently sending packets elsewhere. I 
find this argument hard to swallow.

  If nothing else, a global proxy will not be able to address
> unintentionally sent to any third party.)

The assumption in ICE is that SIP itself works through NAT. Its oodles 
easier to get SIP as a signaling protocol to work through NAT since we 
have centralized intermediareis (aka proxies) which are always in the 
path of SIP signaling.

> surely not a sensible route for the IETF!

The point of ICE is, in fact, to do something about the RTP.
SIP doesnt handle the RTP, so a NAT traversal solution for SIP doesnt 
help the RTP.

> that under these conditions in a properly designed system C is not exposed

Our final system does know about NAT for signaling and RTP. Techniques 
like rport and connection reuse deal with the signaling, making it look 
like client/server, and techniques like ICE help the RTP. The solution 
for RTP is purposefully different than SIP, since the goal is NOT to 
always include an intermediary in all RTP (making it look like client 
server). The costs of the relay, in terms of latency, packet loss, 
bandwidth, system cost, system complexity, and overall availability, are 
higher for RTP than SIP, and thus the different solution.

> SIP and RTP are not the only protocols that run over the Internet!

I don't think anyone in this thread, myself or others, have claimed 
otherwise.

> R1(B):b, unintentionally DoSing C's TFTP session (or whatever).

This is not a DoS attack. It is not a packet flood (indeed, I have 
pointed out how ICE prevents a packet flood that would occur). It is 
most analagous to a stray packet. It sometimes happens. I agree ICE will 
cause this to happen sometimes.

However, I dont think it will be that problematic, because:

1. It only happens when (1) the private address advertised by A happens 
to correspond to another host C in B's realm, (2) the UDP port 
advertised by A happens to be in used by another protocol, (3) the 
protocol listening on that port pukes on a stray packet. I think (1) is 
a reasonably likely event. However, I think (2) is going to be 
relatively rare. The ports advertised by A in its SDP will generally be 
ephemeral, so for this "problem" to occur, another host has to be using 
the same ephemeral UDP port. Given that most UDP apps are transactional 
and use ephemeral ports only briefly, I think the probability is quite 
low. I think the probability of (3) is also low. If its not, it's 
something that needs to be fixed anyway, as it would open the host up to 
  real attacks very easily. Practically speaking, the other protocols 
we're likely to see that use UDP would be DNS and NFS, I think. Have you 
tried sending a stun packet to the client port?

> unintentionally DoSed.  I don't think the IETF should be accepting this

Well, I stronly disagree.

I do not think the problem is that serious (see above). Your proposed 
solution, which was to use DNS resolvability as an indication of shared 
realms, has many problems:

1. As I mentioned, it is based on the very fundamental assumption that a 
DNS server serves a single address realm. I think this assumption is 
flawed. An easy example is an enterprise which runs multi-layer nat (I 
*have* seen this), but has a single internal DNS. The solution is also 
brittle in that, should the address realms change (because someone turns 
on the NAT in a router somewhere), if the DNS doesn't split at the same 
time, your solution doesnt work. It is exactly this kind of brittleness 
- dependency on topology assumptions - which ICE is trying to get away 
from. The primary benefit of ICE is that it doesnt depend on these 
assumptions; it determines that communication is possible by dynamically 
trying. Your solution would re-introduce the problem ICE is trying to fix.

2. Because of the flaw above, the dns trick you propose can only, at 
best, be considered a hint. You still need to try the address, which 
re-introduces the "problem" you are trying to solve.

3. Your proposal depends on the widespread usage and deployment of 
dynamic DNS. I think this is a significant deployment burden, as nearly 
all consumer voip deployments I know of do not make use of DNS for the 
clients.

4. Usage of DNS will further increase call setup latencies.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 23 Sep 2004 10:41:48 +0100

Dan,

Thanks for your mail.  I feel we're on the same page now!

More inline...

----- Original Message ----- 

...
> point in the email that I don't understand the problem you're describing.

OK that's great.

> > unintentionally DoSed. I don't think the IETF should be accepting this

Don't worry about the above (there's some notes in reply to Paul's mail, but
they're unimportant when discussing the technical details as we are here.)

> it won't work).  Is that correct?

That's the gist of it.  But rather than 'know'ing that it won't work, they
'suspect' it won't work.  Jumping ahead here slightly, there's an issue of,
if you suspect you're not in the same realm, do you play it safe and not
attempt to connect directly (even though you may in the end be in the same
realm), or do you decide that the impact of trying it anyway is not that
great and just give it a go?  I don't think the question has a simple
answer, but I think it needs to be considered.

Back you the plot... :-)

> and the STUN server is somewhere in the Internet.  Figure 1:

For the little peer-to-peer STUN part of ICE, the proposal is more like this
setup, although STUN srvr A could be part of Client A.  (Your original
public STUN server is still there, but doesn't play are part in the
particular part of the ICE procedures being discussed here.)
           /           \
          /             \
      +--+--+         +--+--+
      | NAT |         | NAT |
      +--+--+         +--+--+
         |               |
     +---+----+      +---+----+
     |Client A|      |Client B|
     +---+----+      +---+----+
         |               |
         |  +--------+   |
         +--+ Router +---+
         |  +--------+
         |
  +-------------+
  | STUN Srvr A |
  +--+-------+--+
(I hope that looks better on your screen than it does mine!)

So the proposal is to publish a DNS resolvable name for STUN srvr A in the
messages that A sends to B rather than an explicit IP address.  B then tries
to resolve that into an IP address using DNS.  If it is unable to resolve an
IP address for STUN srvr A, or it gets a public address, it assumes that
Client A is in a different realm and proceeds no further.  If B gets a
private address, it can then proceed with more direct tests with Client A,
much as exist in ICE already.  One of the reasons for making STUN srvr A
separate is that it would be easier to ensure that it was part of the DNS in
a similar way to an internal web server.

Addressing your second network setup specifically, my feeling is that if
Client B can address a web server on Client A's side of the router
(presumably one of the reasons why the network is joined), then it should
also be able to address a STUN server on Client A's side of the router.
Hence, they should conclude that they are in the same realm!

As I mentioned above, it's probably not 100% fool proof, but it comes down
to whether you err on the side of caution, or feel the risks of upsetting
someone else are not that great.  Call it risk management!

> -d
Pete

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 23 Sep 2004 11:54:54 +0100

----- Original Message ----- 
From: "Jonathan Rosenberg" <[email-masked]>

> "considers the whole system".

I keep getting replies that say something to the effect of "ICE only works
with RTP" etc.  This suggests to me that people are only considering the RTP
/ STUN issues rather than the bigger picture, hence they are missing my
point.

I think the attack mentioned in your denial of service document is
different.  There someone is intentionally being malicious.  In that case
ICE does help.  Here someone is trying to do the right thing, but still
causing problems.  My suggestion is that there is scope for improving ICE so
that these unintentional bad things don't happen.

> find this argument hard to swallow.

Depends whether you're C, or A & B!

> have centralized intermediareis (aka proxies) which are always in the

Agreed, ICE is not concerned with SIP signalling.  But most SIP systems will
need to do something to be addressible across a NAT, such as rport,
persistent TCP connections, continual registers, possibly some special
proxies that know about NATs.  That is NAT awareness for the signalling.
The point I was trying to make is that it is wrong to take steps to get the
signalling through NAT, but then do nothing to get the RTP through the NAT,
because that's one of the cases when packets end up at the wrong place.

> SIP doesnt handle the RTP, so a NAT traversal solution for SIP doesnt

Agreed.

> higher for RTP than SIP, and thus the different solution.

Fine - no issue with that (today!).

> I don't think anyone in this thread, myself or others, have claimed

Pls see my note about my interpretation of comments like "ICE only works
with RTP".  Maybe crossed wires!

> cause this to happen sometimes.

I think it depends on how problematic it is to C.  Pulling the plug out of C
would surely cause it to lose service.  I'm assuming that not all DoS
attacks are flood attacks.

A quick note before addressing the issues you raise below.  I think this is
a really good starting point for an analysis of whether the situation is a
problem.  I'm on the fence about whether this is a real problem or not.  I
like 100% solutions; that seems to be what computers are about.  But maybe
this is a statistical thing and we accept the risks.  I would like to get
other peoples input on this to build a consensus.

> tried sending a stun packet to the client port?

This is good analysis, and I'm glad we are getting to the meat of the
matter.  I actually agree with much of what you say.  To carry on the
anaylsis, we probably need to know the basis of how DHCP hands out
addresses.  If there's a small number of hosts, does it tend to hand out
similar addresses, or does it cycle through the whole range?  What fraction
of the total DHCP allocated address range would be used in a typical
enterprise?  If we take an enterprise as 100 hosts and the 192.168 address
range is used, then there is a far chance of overlap, which backs you your
point of (1).  Your point (2) is probably harder to address.  My experience
is that ports are allocated sequentially.  Hence, although the dynamic
ranges I have seen is 4096 ports big, they will all start allocating from
1024 etc.  If machines are frequently re-booted (e.g. daily) then most ports
will be allocated from the lower end of the range.  This grouping increases
the possibility of a collision.  Whether UDP protocols will be phased by
receiving miscellaneous STUN packets (your point (3)), I really don't know.
Hence the reason for asking input from the list.

> Well, I stronly disagree.

Possibly depends on whether your interpreting "partial solution for NATs" in
the same way I am.

> realms, has many problems:

Actually, much of the reason for proposing a solution is that I didn't want
to be seen as purely knocking ICE.  By including a proposal I was saying
that this issue bothers me, but we can mend it by doing this.  The real
issue is whether the described problem is really a problem!  If nothing
else, I would like to see some analysis such as above in the Security
Considerations section to say this is what we considered, and this is what
we concluded.  Then if somebody brings up the same issue in future you can
just refer them to the paragraph!

> trying. Your solution would re-introduce the problem ICE is trying to fix.

I was unsure whether having decided that the two clients might be in the
same realm using the proposed solution they should try STUN direct as per
current ICE.  You've now convinced me that they should.

> re-introduces the "problem" you are trying to solve.

I think the 'hint' will either yield 'you are in the same realm', or 'you
are probably not in the same realm'.  How you progress from there needs to
be decided.  If you think the risk of upsetting things is low, then you
could say 'I'll try it anyway' (although you did waste your time doing the
test!)  Or you could say 'I'll play it safe' and assume I'm not in the same
realm.  I certainly think that in the enterprise case there are steps you
could take to make it work if the network administrators thought there was
enough demand (and ICE, being clever, would find the desired route)

> all consumer voip deployments I know of do not make use of DNS for the

I don't have a feel for this.  As mentioned in my earlier mails, my only
experience of this is Windows and the configuration seems to happen by
magic!  What stand-alone phones do I don't know.  I imagine the OS has the
networking built in.  Most IP kits seem to bundle a vast amount of
protocols, so I wouldn't be surprised if the dynamic DNS stuff was already
in there.  (Actually I did consider that the DHCP server would take care of
this.  Obviously not!)

> 4. Usage of DNS will further increase call setup latencies.

Actually, I don't think this is a problem with ICE.  If ICE finds the
'longer' route first, it will start using that, and when it finds the
shorter route it will switch over to that.  Magic!

> Jonathan R.

I think we have made a lot of progress on this issue here.  I think we are
now debating the same thing and know what each other think.  It would be
nice to get some other opinions as to whether we have a problem here or not.
And, if it is a problem, whether it is easy to solve or not (by whatever
means).

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 23 Sep 2004 09:50:18 +0100

From: "Paul Kyzivat" <[email-masked]>
> > unintentionally DoSed.  I don't think the IETF should be accepting this

To clarify, "partial solution for NATs" refers to getting the signalling
through but doing nothing special for the RTP.  If you then add in the
peer-to-peer STUN part of ICE, you can improve things, but the damage is
still done; just less of it.

> that ICE is the wrong solution.

No.  I'm suggesting that ICE is mostly right, but just needs to fix a little
area of its operation that possibly hasn't been considered before.

Pete