Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP : better guidance?

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Sep 2007 11:46:39 -0700

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: Friday, August 24, 2007 8:22 AM
> To: Jeroen van Bemmel; sipping; [email-masked]
> Cc: [email-masked]; Gonzalo Camarillo
> Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 
> symmetric RTP : better guidance?
> 
> Ah.... I get it now.
>  
> Yes, I agree.
>  
> In fact, I'm not even sure we should even say anything about 
> "second guessing". We have a standards-based solution for 
> this, and it's ICE. We should probably stick to recommending that.

Further, recommending (2) -- or building a product which does (2) --
leaves you open to an attacker that sends RTP packets to a certain
port all day long, hoping you'll eventually start listening on that
port.  If you do (2), you'll establish bi-directional media with
the attacker (rather than the intended endpoint).  This isn't good.

-d

> The fact that many devices (SBCs, etc) do second guess is 
> just a fact of life. We could mention that it happens, but I 
> don't think we should recommend doing it, or provide any 
> guidance on when it is appropriate. We should just say "some 
> devices use tricks like using a media relay, second guess the 
> IP address and port based on symmetric RTP assumptions, but 
> our recommended approach is ICE.
>  
> My 2 cents.
> 
> 
> ________________________________
> 
> 	From: Jeroen van Bemmel [mailto:[email-masked]] 
> 	Sent: Thursday, August 23, 2007 23:10
> 	To: Audet, Francois (SC100:3055); sipping; [email-masked]
> 	Cc: [email-masked]; Gonzalo Camarillo
> 	Subject: Re: [Sipping] sipping-nat-scenarios section 
> 3.2.1 symmetric RTP : better guidance?
> 	
> 	
> 	Francois,
> 	 
> 	I think there's two sides to this:
> 	1) send/receive RTP using the same socket/port (and 
> idem for RTCP)
> 	2) "second guess" the IP address/port announced in SDP, 
> assume the sender is doing (1) and send RTP/RTCP packets to a 
> ip/port combination received in a RTP/RTCP packet
> 	 
> 	For (1) we should say: it is RECOMMENDED to do this
> 	For (2) it is more tricky. For starters, it would be 
> nice if the SDP carried some flag to indicate that (1) is the 
> case (i.e. peer is doing symmetric RTP/RTCP). And then still 
> we need to provide more guidance on when to do (2)
> 	 
> 	Regards,
> 	Jeroen
> 
> 		----- Original Message ----- 
> 		From: Francois Audet <mailto:[email-masked]>  
> 		To: Jeroen van Bemmel 
> <mailto:[email-masked]>  ; sipping 
> <mailto:[email-masked]>  ; [email-masked] 
> 		Cc: [email-masked] ; Gonzalo 
> Camarillo <mailto:[email-masked]>  
> 		Sent: Thursday, August 23, 2007 6:10 PM
> 		Subject: RE: [Sipping] sipping-nat-scenarios 
> section 3.2.1 symmetric RTP : better guidance?
> 
> 		Actually, it's exactly the opposite of what we 
> should do. 
> 		 
> 		We should say that Symmetric RTP SHOULD always be used.
> 		 
> 		We should point to RFC 4961 which states the following:
> 
> 			There are no known cases where 
> symmetric RTP or symmetric RTCP are harmful.
> 			 
> 			For these reasons, it is RECOMMENDED 
> that symmetric RTP and symmetric RTCP always be used for 
> bidirectional RTP media streams.
> 
> 		Cheers.
> 
> 
> ________________________________
> 
> 			From: Jeroen van Bemmel 
> [mailto:[email-masked]] 
> 			Sent: Tuesday, August 21, 2007 09:50
> 			To: sipping
> 			Cc: [email-masked]; 
> Gonzalo Camarillo
> 			Subject: [Sipping] 
> sipping-nat-scenarios section 3.2.1 symmetric RTP : better guidance?
> 			
> 			
> 			All,
> 			 
> 			A comment on 
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce
> narios-07
> 			 
> 			Section 3.2.1 symmetric RTP last 
> paragraph currently reads:
> 			"'Symmetric RTP' SHOULD only be used 
> for traversal of RTP through NAT when one of the participants 
> in a media session definitively knows that it is on the 
> public network."
> 			 
> 			Isn't it possible to provide more 
> accurate / concrete guidance? something like "an endpoint 
> SHOULD NOT use 'Symmetric RTP' unless it can determine that 
> the address received in the SDP offer/answer is not routable?"
> 			 
> 			Regards,
> 			Jeroen
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Sep 2007 10:59:54 -0400

> From: Dan Wing [mailto:[email-masked]]
> Sent: Friday, September 07, 2007 2:47 PM
> 

Then someone building such a product should take precautions to avoid such
things, or notify someone.  But then such an attack seems quite benign to
me.  The real caller will hang up pretty quickly when they don't get audio. 
And the attacker won't have been able to focus on a particular caller/called
party to do this to, so it's more of an annoyance than anything else... not
very profitable.  ;)

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Sep 2007 10:59:54 -0400

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Sep 2007 10:59:54 -0400

I agree.  In fact I'd say symmetric RTP/RTCP MUST be used, unless the UA
cannot do so - since I agree with Henning's statement a while ago that
"SHOULDs" are basically toothless.

ICE-aided NAT/FW traversal requires symmetric RTP.  Non-ICE NAT/FW traversal
requires symmetric RTP.  Some networks which police or prioritize flows
require symmetric RTP.  Etc.

-hadriel
p.s. and "second guessing" is definitely not something that should be
standardized.

________________________________________
From: Francois Audet [mailto:[email-masked]] 
Sent: Friday, August 24, 2007 11:22 AM
To: Jeroen van Bemmel; sipping; [email-masked]
Cc: [email-masked]; Gonzalo Camarillo
Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP
:better guidance?

Ah.... I get it now.
 
Yes, I agree.
 
In fact, I'm not even sure we should even say anything about "second
guessing". We have a standards-based solution for this, and it's ICE. We
should probably stick to recommending that.
 
The fact that many devices (SBCs, etc) do second guess is just a fact of
life. We could mention that it happens, but I don't think we should
recommend doing it, or provide any guidance on when it is appropriate. We
should just say "some devices use tricks like using a media relay, second
guess the IP address and port based on symmetric RTP assumptions, but our
recommended approach is ICE.
 
My 2 cents.

________________________________________
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Thursday, August 23, 2007 23:10
To: Audet, Francois (SC100:3055); sipping; [email-masked]
Cc: [email-masked]; Gonzalo Camarillo
Subject: Re: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP :
better guidance?
Francois,
 
I think there's two sing by megatron.ietf.org with local (Exim 4.43)
	id 1IVqFb-0005RJ-Tb for [email-masked];
	Thu, 13 Sep 2007 11:05:03 -0400
From: "Hadriel Kaplan" <[email-masked]>
To: "'Francois Audet'" <[email-masked]>,
	"'Jeroen van Bemmel'" <[email-masked]>, "'sipping'" <[email-masked]>,
	<[email-masked]>
Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP
	:better guidance?
Date: Thu, 13 Sep 2007 10:59:54 -0400
Cc: [email-masked],
	'Gonzalo Camarillo' <[email-masked]>

I agree.  In fact I'd say symmetric RTP/RTCP MUST be used, unless the UA
cannot do so - since I agree with Henning's statement a while ago that
"SHOULDs" are basically toothless.

ICE-aided NAT/FW traversal requires symmetric RTP.  Non-ICE NAT/FW traversal
requires symmetric RTP.  Some networks which police or prioritize flows
require symmetric RTP.  Etc.

-hadriel
p.s. and "second guessing" is definitely not something that should be
standardized.

________________________________________
From: Francois Audet [mailto:[email-masked]] 
Sent: Friday, August 24, 2007 11:22 AM
To: Jeroen van Bemmel; sipping; [email-masked]
Cc: [email-masked]; Gonzalo Camarillo
Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP
:better guidance?

Ah.... I get it now.
 
Yes, I agree.
 
In fact, I'm not even sure we should even say anything about "second
guessing". We have a standards-based solution for this, and it's ICE. We
should probably stick to recommending that.
 
The fact that many devices (SBCs, etc) do second guess is just a fact of
life. We could mention that it happens, but I don't think we should
recommend doing it, or provide any guidance on when it is appropriate. We
should just say "some devices use tricks like using a media relay, second
guess the IP address and port based on symmetric RTP assumptions, but our
recommended approach is ICE.
 
My 2 cents.

________________________________________
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Thursday, August 23, 2007 23:10
To: Audet, Francois (SC100:3055); sipping; [email-masked]
Cc: [email-masked]; Gonzalo Camarillo
Subject: Re: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP :
better guidance?
Francois,
 
I think there's two sides to this:
1) send/receive RTP using the same socket/port (and idem for RTCP)
2) "second guess" the IP address/port announced in SDP, assume the sender is
doing (1) and send RTP/RTCP packets to a ip/port combination received in a
RTP/RTCP packet
 
For (1) we should say: it is RECOMMENDED to do this
For (2) it is more tricky. For starters, it would be nice if the SDP carried
some flag to indicate that (1) is the case (i.e. peer is doing symmetric
RTP/RTCP). And then still we need to provide more guidance on when to do (2)
 
Regards,
Jeroen
----- Original Message ----- 
From: Francois Audet 
To: Jeroen van Bemmel ; sipping ; [email-masked] 
Cc: [email-masked] ; Gonzalo Camarillo 
Sent: Thursday, August 23, 2007 6:10 PM
Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP :
better guidance?

Actually, it's exactly the opposite of what we should do. 

We should point to RFC 4961 which states the following:
There 
      are no known cases where symmetric RTP or symmetric RTCP are 
      harmful.
 
For 
      these reasons, it is RECOMMENDED that symmetric RTP and symmetric RTCP

      always be used for bidirectional RTP media 
      streams.
Cheers.

________________________________________
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2007 09:50
To: sipping
Cc: [email-masked]; Gonzalo Camarillo
Subject: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP :
better guidance?
All,
 
A comment on
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07
 
Section 3.2.1 symmetric RTP last paragraph currently reads:
"'Symmetric RTP' SHOULD only be used for traversal of RTP through NAT when
one of the participants in a media session definitively knows that it is on
the public network."
 
Isn't it possible to provide more accurate / concrete guidance? something
like "an endpoint SHOULD NOT use 'Symmetric RTP' unless it can determine
that the address received in the SDP offer/answer is not routable?"
 
Regards,
Jeroen

des to this:
1) send/receive RTP using the same socket/port (and idem for RTCP)
2) "second guess" the IP address/port announced in SDP, assume the sender is
doing (1) and send RTP/RTCP packets to a ip/port combination received in a
RTP/RTCP packet
 
For (1) we should say: it is RECOMMENDED to do this
For (2) it is more tricky. For starters, it would be nice if the SDP carried
some flag to indicate that (1) is the case (i.e. peer is doing symmetric
RTP/RTCP). And then still we need to provide more guidance on when to do (2)
 
Regards,
Jeroen
----- Original Message ----- 
From: Francois Audet 
To: Jeroen van Bemmel ; sipping ; [email-masked] 
Cc: [email-masked] ; Gonzalo Camarillo 
Sent: Thursday, August 23, 2007 6:10 PM
Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP :
better guidance?

Actually, it's exactly the opposite of what we should do. 

We should point to RFC 4961 which states the following:
There 
      are no known cases where symmetric RTP or symmetric RTCP are 
      harmful.
 
For 
      these reasons, it is RECOMMENDED that symmetric RTP and symmetric RTCP

      always be used for bidirectional RTP media 
      streams.
Cheers.

________________________________________
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Tuesday, August 21, 2007 09:50
To: sipping
Cc: [email-masked]; Gonzalo Camarillo
Subject: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric RTP :
better guidance?
All,
 
A comment on
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07
 
Section 3.2.1 symmetric RTP last paragraph currently reads:
"'Symmetric RTP' SHOULD only be used for traversal of RTP through NAT when
one of the participants in a media session definitively knows that it is on
the public network."
 
Isn't it possible to provide more accurate / concrete guidance? something
like "an endpoint SHOULD NOT use 'Symmetric RTP' unless it can determine
that the address received in the SDP offer/answer is not routable?"
 
Regards,
Jeroen

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Sep 2007 08:42:14 -0700

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 8:00 AM
> To: 'Dan Wing'; 'Francois Audet'; 'Jeroen van Bemmel'; 'sipping'
> Cc: [email-masked]; 'Gonzalo Camarillo'
> symmetric RTP :better guidance?
> 
> 
> 
> Then someone building such a product should take precautions 
> to avoid such things, or notify someone. 

Randomizing ports only gets you so far -- the attacker can just
send to one (or a dozen) ports, knowing that eventually you'll
use them and their audio will get played.

> But then such an attack seems quite benign to

The real caller wouldn't hear dead air -- rather, the real
caller will hear an advertisement, political propaganda,
or whatever the attacker wanted to send.

> party to do this to, so it's more of an annoyance than 
> anything else... not very profitable.  ;)

I know the Viagra advertisements that I receive aren't
targeted to me, yet sending such advertisements must
be profitable (or else they would send other 
advertisements!)

It isn't just spamming, and it need not be financially
profitable.  You could imagine someone that doesn't 
like a company for some reason and sending white 
noise (encoded in RTP) or "your product is lousy,
you should be ashamed to work there" or "join our
union to get healthcare from your employer".  

What will SIP's reaction to that be?  "Gosh, just
hang up and you'll get a new ephemeral port."?

If you're saying there are bigger fish to fry, I'll
sit back down.  But if we're serious about getting
SIP on the Internet, this seems like a real problem
worth solving.  The easiest solution is wait for the
SDP answer, but that breaks a lot of early media that
folks enjoy.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Sep 2007 11:11:52 -0500

> p.s. and "second guessing" is definitely not something that 
> should be standardized.

Offer/Answer?

Ah ah ah...

---

From: Jeroen van Bemmel <[email-masked]>
Date: Thu, 13 Sep 2007 23:14:15 +0200

Like I said - I think we need a flag for symmetric RTP being used, 
something like the 'rport' flag at the SIP level. Then if the sender 
port is different from the port announced in the SDP, the receiver can 
tell that there's port NAT, and it's no longer a guess

Regards,
Jeroen

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Sep 2007 16:24:06 -0500

I think it's too late for that unfortunately.

Most implementations already use symmetric ports, with no flag. 

> Sent: Thursday, September 13, 2007 14:14
> To: Audet, Francois (SC100:3055)
> Cc: Hadriel Kaplan; sipping; [email-masked]; 
> [email-masked]; Gonzalo Camarillo
> Subject: Re: [Sipping] sipping-nat-scenarios section 3.2.1 
> Like I said - I think we need a flag for symmetric RTP being 
> used, something like the 'rport' flag at the SIP level. Then 
> if the sender port is different from the port announced in 
> the SDP, the receiver can tell that there's port NAT, and 
> it's no longer a guess
> 
> Regards,
> Jeroen
> 
> Francois Audet wrote:
> >  
> >
> >

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 13 Sep 2007 17:28:45 -0400

> Sent: Thursday, September 13, 2007 11:42 AM
>

Who said randomizing ports? :)
I assumed the basis for your argument was that randomizing ports would not
be enough because the number space is finite and relatively small.
(Although someone just pointed out to me the other day there are ways of
making the space very, very large someday)

I just meant if an attacker has to send a packet stream for a long time to
closed/unusued ports, then one can detect, notify, and react to that.  

> or whatever the attacker wanted to send.

Then the called side would hang up.  Unless you're saying the attacker can
send media to both caller and called sides.  The scenario you described was
when an attacker takes advantage of "second-guessing" techniques - such a
thing would divert media to the attacker for one of the directions, and thus
that media would not go to the right place, and would not be heard, and that
side of the call would hang up... eventually.

> profitable.  

Yup, good point.

> hang up and you'll get a new ephemeral port."?

It would be "use SRTP auth" I assume.  This isn't a problem specific to
second-guessing systems.  Any device can have this problem.

> sit back down.  

That was my thinking, but that attack scenario has come up before (not as in
actually been seen, but as in worried about).  I still think the threat
level is low though... mostly because there are easier attack points.

> But if we're serious about getting

SRTP needs the SDP answer, ICE needs the SDP answer, etc.  I liked your
early-media-srtp draft idea, but I guess perfect beat out good.  :(

-hadriel

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 14 Sep 2007 09:30:32 +0300

> closed/unusued ports, then one can detect, notify, and react to that.

Depends how busy the SBC is, since the probability of finding a matching port 
is proportional to the rate at which RTP sessions are established. Worse, if 
it automagically tries to work around NAT mapping change, then the 
probability is proportional to the number of running RTP sessions.

The implementations I tested did not even bother randomizing the port number 
(it was incremented from call to call). And they did not check for scanning, 
understandably so because that would require some in-depth integration 
between the firewall and the proxying software:

http://www1.ietf.org/mail-archive/web/sip/current/msg19969.html

But anyway, I think we agree this is pretty bad and should definitely not be 
standardized. It strikes as very dishonest marketing that SBCs are supposed 
to "secure" the network, while it is actually creating a big wide hole of its 
whole.

Again, I strongly suggest the second guessing stuff be removed from 
nat-scenarios, and/or there be a not how insecure it is:
http://www1.ietf.org/mail-archive/web/sipping/current/msg14425.html

Regards,

-- 
Rémi Denis-Courmont

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 14 Sep 2007 12:03:14 -0400

> From: Rémi Denis-Courmont [mailto:[email-masked]]
> Sent: Friday, September 14, 2007 2:31 AM
> To: [email-masked]
> Subject: Re: [Sipping] sipping-nat-scenarios section 3.2.1 symmetric
> RTP:better guidance?
> 

I'm not sure I understand what you mean by that.  Finding a matching port to
what?

> (it was incremented from call to call). 

I have seen that too in some SBCs, but if you look at traces of a live
network, it is random - purely because calls don't stop in the same sequence
they started, and some calls are very short while others very long, so a
while after a start/ramp-up duration the next port number the SBC offers
becomes hard to guess. (and different SBCs seem to increment by different
offsets)

> And they did not check for
> scanning,

I think that depends a lot on the architecture.  Even if the media plane is
done in hardware then often there are ways of detecting scans, without
exposing oneself to resource attacks. (firewalls have been doing that for a
long time)  

> It strikes as very dishonest marketing that SBCs are
> supposed

And that is a very general, broad statement.  You can't test a
software-based media proxy like openSER, and make a general claim against a
whole category of devices.  Like anything, there will be some products which
are better at some things, and some which are worse.  I've personally tested
one of the leading general-purpose firewalls (probably the most popular
one), and was able to make it lock up in a directed SIP attack in less than
20 seconds.  But I don't blame "firewalls" as being insecure, or
misrepresenting themselves.  

With regards to "second guessing" techniques, no one said it was a security
measure.  It was a way to make NATed calls work.  Before SBCs there was no
way to get calls to work across NATs.  Even today the number of endpoints,
gateways, media servers, etc. that support ICE is very, very small, relative
to the total.  But that's really orthogonal to security.

And there are ways of making "second-guessing" and latching far more secure
than your emails claim them to be.  For starters, in the vast majority of
deployments, the SBC can restrict its latching to be only from the same IP
address, or some small mask thereof, as the signaling.  That way an attacker
would have to guess the source address as well.  I know that's not
architecturally pure from a SIP point of view, but it's pragmatically
effective.  There are a few deployments I've seen where that technique won't
work, but there is an alternate technique which at least one vendor (mine)
has used which does a similar thing for those networks. 

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Sep 2007 10:14:27 -0700

> Who said randomizing ports? :)

I assumed that is what you were referring to.  Is there some other
protection that is useful (short of ICE)?

> be enough because the number space is finite and relatively small.

It's better than using fixed or predictable ports.  But the 
attacker need only be successful some of the time to get their
advertisement (or whatever) through.

> (Although someone just pointed out to me the other day there 
> are ways of making the space very, very large someday)

Today, you can use multiple IP addresses on a single interface 
to help make the space larger.

> I just meant if an attacker has to send a packet stream for a 
> long time to closed/unusued ports, then one can detect, notify, 
> and react to that.  

What will you do?  Slashdot recently reported there is a bot
that is estimated to have a few million PCs.

> Then the called side would hang up.  Unless you're saying the 
> attacker can send media to both caller and called sides. 

If they're both running SBCs, there could be separate attacks
on both sides going on.  But I don't see how an (off-path)
attacker could send the same RTP stream to both ends unless
the port numbers were easily guessed.

> The scenario you described was

Right.

I feel we can (and should) do better than relying on one end
hanging up because they got dead air (or an advertisement).

> second-guessing systems.  Any device can have this problem.

SRTP authentication doesn't quite do it, unless we also 
disallow RTP.  We know it'll take years -- perhaps a decade --
to get SRTP rolled out everywhere.  In the meantime, we'll
have offers that allow RTP fallback (via your previous I-D,
via SDP grouping, or via MMUSIC's SDP Capability Negotiation).

> That was my thinking, but that attack scenario has come up 
> before (not as in actually been seen, but as in worried 
> about).  I still think the threat level is low though... mostly 
> because there are easier attack points.

Alright.  I'll sit down then and quit waving my arms wildly about
this attack scenario.

> SRTP needs the SDP answer, ICE needs the SDP answer, etc.  I 
> liked your early-media-srtp draft idea, but I guess perfect 
> beat out good.  :(

Yeah, oh well.

-d

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 14 Sep 2007 14:31:43 -0400

> Sent: Friday, September 14, 2007 1:14 PM
> >

Yes, there are a few.  But none of them are architecturally nice.  All the
ones I've seen revolve around guessing and restricting the source address of
the sender, using various means.  The most common is assuming the signaling
source IP address is the same, or very close to it (ie, SIP went through a
NAT, so the media will too).  That works well for service provider
subscriber access, but not always well for enterprise access or peering.
You can probably guess how it can be done in other similar ways for them.
(not sure how much I can say, given this may be competitively
differentiating as far as I know)

> to help make the space larger.

Yup, and that's already done.  But with IPv6 the available local-device
space becomes enormous - the same or bigger than the IPv4 address space in
total.  So someday (when IPv6 becomes more ubiquitous), it could be taken
advantage of.

> that is estimated to have a few million PCs.

Yup, and zombies are obviously the most worrisome - real zombies, where the
zombie is a legitimate SIP endpoint for the domain.  Again I'm not sure how
much detail is known or supported by all vendors, vs. specific ones, so I'm
not going to detail it.  But right now an attack from zombies would
essentially remove them from the network, for those operators that can and
wish to do so, and not impact non-zombies. (although it depends on what the
zombies do)  

But I have no doubt this will be an arms race.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Sep 2007 13:18:23 -0700

> differentiating as far as I know)

Yes, I know of some vendors equipment that does this.  It has the
weaknesses you describe above.

> total.  So someday (when IPv6 becomes more ubiquitous), it 
> could be taken advantage of.

I'll let my daughter know.  :-)

> zombie is a legitimate SIP endpoint for the domain. 

That's a problem, too.  But even a zombie that isn't a real
SIP endpoint can send UDP/RTP packets to an SBC's (or NAT's or
phone's) IP address, hoping there is a listener on that UDP
port.

> Again I'm not sure how
> essentially remove them from the network, for those operators 
> that can and wish to do so, and not impact non-zombies. (although 
> it depends on what the zombies do)  
> 

-d

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Sat, 15 Sep 2007 13:58:01 -0400

> phone's) IP address, hoping there is a listener on that UDP

Of course, but those are generally easier to stop or ignore than real SIP
zombies, for devices which already know which IP's belong to which
legitimate SIP users for the domain.

-hadriel

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 17 Sep 2007 09:18:43 +0300

Le Friday 14 September 2007 19:03:14 ext Hadriel Kaplan, vous avez écrit :
> I'm not sure I understand what you mean by that.  Finding a matching port
> to what?

Finding a port that the SBC expects traffic on during the window when you can 
probe it.

> > The implementations I tested did not even bother randomizing the port
> > number (it was incremented from call to call).
>
> network, it is random - purely because calls don't stop in the same
> sequence they started, and some calls are very short while others very
> long, so a while after a start/ramp-up duration the next port number the
> SBC offers becomes hard to guess. (and different SBCs seem to increment by
> different offsets)

Not necessarily true.
Some implementations simply increment the port number from call to call, and 
only go back to the beginning when the number wraps. At that point, the calls 
that got the initial numbers are likely most completed, so port allocation 
remain almost incremental for as long as the SBC vendor fails to upgrade its 
insecure software/hardware.

> > It strikes as very dishonest marketing that SBCs are supposed to
> > "secure" the network, while it is actually creating a big wide hole
> > of its whole.
>
> whole category of devices.

The theoretical maximum entropy a SBC can provide is (not using the privileged 
part range, and obeying RTP/RTCP port parity):

log2(65536-1024) - 1 + log2(n_IP)

where n_IP>0 is the number of IP addresses the SBC has.
Since when are 15 bits of entropy considered good enough for security reasons?
(ICE has 128 bits from memory).

> Like anything, there will be some products which are better at some things,
> and some which are worse.  I've personally tested one of the leading
> general-purpose firewalls (probably the most popular one), and was able to
> make it lock up in a directed SIP attack in less than 20 seconds.  But I
> don't blame "firewalls" as being insecure, or misrepresenting themselves.

There is a very fundamental difference between implementation bugs (crashing 
the firewall) and fundamental architectural flaws (port latching).

From a *security*-only perspective, I have no problem with a SBC that does NOT 
do port latching.

> gateways, media servers, etc. that support ICE is very, very small,
> relative to the total.  But that's really orthogonal to security.
>
> address, or some small mask thereof, as the signaling.

So how do I calls to/gets called by third parties? The SIP signaling IP 
address will be their proxies', but the media address will be their own.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 17 Sep 2007 09:40:20 +0300

> relative to the total.  But that's really orthogonal to security.

Heck, I know there are virtually no ICE-enabled device at the moment. My 
employer does not ship any at the moment, as far as I know. And even if there 
were, if you have bad-behaving NATs and no TURN server, it would not work.

But then, my point is not to make FCC and CE take legislation against port 
latching. My point is that the nat-scenario document should not encourage 
that method, if not discourage it.

-- 
Rémi Denis-Courmont

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 17 Sep 2007 13:14:56 -0700

> Some implementations simply increment the port number from 
> call to call, and only go back to the beginning when the number 
> wraps. At that point, the calls that got the initial numbers 
> are likely most completed, so port allocation remain almost 
> incremental for as long as the SBC vendor fails to upgrade 
> its insecure software/hardware.

draft-larsen-tsvwg-port-randomization was recently posted to
some other mailing lists by Lars (reference
<http://www1.ietf.org/mail-archive/web/tsvwg/current/msg07901.html>).

That I-D contains a good analysis of the benefits of randomization 
and the current state-of-the-art.

-d

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 18 Sep 2007 17:49:36 -0400

> (ICE has 128 bits from memory).

Again, you make it sound like they had some alternate choice, such as ICE.
SRTP would also provide a very good auth scheme (better), if devices
supported it.  But there was no alternate choice.  It was do port latching,
or not have calls work.  In real-world deployment scenarios the SBC can
restrict the latching source IP to provide better entropy, like ~48 bits
total, but my guess is it's effectively more like 32 bits.  That's still not
very strong, but hopefully will buy time for SRTP to gain in popularity.

> the firewall) and fundamental architectural flaws (port latching).

Agreed, but the "architecture" flaw is not one of SBCs as a category, but
rather of a mechanism (a feature) to make NAT traversal work pre-ICE, and
pre-SRTP authentication.  Some firewalls also offer this latching type of
mechanism, as do some media gateways.  Fixing NAT traversal is not the
raison d'etre for SBCs, and indeed there are SBCs out there that don't fix
NAT traversal, and don't do latching at all.

> address will be their proxies', but the media address will be their own.

Well, one can usually tell when a proxy is in the path by looking at
signaling.  One could also inspect some of that signaling to determine what
the endpoint's real IP Address is, if the NAT is somewhere between the
endpoint and that proxy, and restrict the media to match that. (and some
not-so-proxy vendors have proprietary headers to tell you it)

In my application space, which is probably different than your's but I think
is not unusual, the service provider world is essentially broken up into
three different types of voip "connections" - subscriber, enterprise, and
peering.  Subscribers would be the home phone or IAD/MTA types, which almost
never have proxies in between them and the SBC, and even when they do the
proxy is behind the same NAT.  Enterprises often do have proxies, but
they're either behind the same NAT, or they're provisioned address ranges
anyway, or they fix NAT traversal themselves.  Peering (inter-provider
connections) one would think would be harder, but for my customer base each
service provider fixes their own subscribers and enterprises' NAT issues, so
one rarely does latching on peering connections.  There are scenarios
in-between, which is why some vendors added proprietary headers.

But I'm sure other people have different views and different applications.
My only point was that the port latching behavior is not as open as one
might think, and considering there was no choice, it's not hard to see why
it was done.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 Sep 2007 15:08:02 -0700

I agree with your email.

Getting back to draft-ietf-sipping-nat-scenarios and Remi's complaint: would
it make sense to add text to draft-ietf-sipping-nat-scenarios describing why
latching was (and is) done, its weakness, and that ICE is expected to remove
the need for latching as ICE gets deployed into endpoints and SBCs become
aware of ICE and utilize ICE to avoid the weaknesses of latching.

-d

> Sent: Tuesday, September 18, 2007 2:50 PM
> To: 'Rémi Denis-Courmont'
> Cc: [email-masked]
> symmetricRTP:better guidance?
> 
> 
> 
> > Since when are 15 bits of entropy considered good enough 
> for security
> > reasons?
> > > And there are ways of making "second-guessing" and 
> latching far more
> > secure
> > > than your emails claim them to be.  For starters, in the 
> vast majority
> > of
> > > deployments, the SBC can restrict its latching to be only 
> from the same
> > IP

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 19 Sep 2007 16:07:02 -0400

Oh right, there's actually a draft under discussion. :)  I don't think this
draft should go down that path.  The purpose of the draft I assume is to be
a BCP of how to handle NAT traversal generally from the IETF's perspective,
and that's what it does.  If you start discussing other methods of
performing it, and try to give pro's/con's, it will go down a rat-hole that
becomes dependent on specific device capabilities and specific network
architectures and philosophies.  We will argue about even the most basic of
assumptions, when at the end of the day it won't make a difference, IMHO -
those that want to use/support ICE will, those that won't, won't.  The
market will decide that, not an RFC.

-hadriel

> Sent: Tuesday, September 18, 2007 6:08 PM
> To: 'Hadriel Kaplan'; 'Rémi Denis-Courmont'
> Cc: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Sep 2007 15:26:38 -0700

I wasn't expecting the document to get into that rathole; rather,
just to point a way out -- an 'escape'.  We do this with RTP 
("use SRTP to avoid listening in", without getting into details
about how that might be done).  I'm thinking merely a sentence,
like:

  At the time of this writing, ICE appears that it may provide
  a useful mechanism to avoid the drawbacks of latching; however,
  ICE is not yet widely available.

-d

> Sent: Wednesday, September 19, 2007 1:07 PM
> To: 'Dan Wing'; 'Rémi Denis-Courmont'
> Cc: [email-masked]
> > Getting back to draft-ietf-sipping-nat-scenarios and Remi's 
> complaint:
> > would
> > it make sense to add text to 
> draft-ietf-sipping-nat-scenarios describing
> > why
> > latching was (and is) done, its weakness, and that ICE is 
> expected to
> > remove
> > > > > software-based media proxy like openSER, and make a 
> general claim
> > > > against a
> > > > The theoretical maximum entropy a SBC can provide is 
> (not using the
> > > > privileged
> > > > There is a very fundamental difference between 
> implementation bugs
> > > > (crashing
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 26 Sep 2007 11:58:44 +0100

Hi folks (apologies - just catching up after vacation).  I am happy to include such information if the group agrees.  I'm not personally sure if it is required in this BCP.  I certainly don't want promotion by association :-).

Chris.

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: 19 September 2007 23:27
To: 'Hadriel Kaplan'; 'Rémi Denis-Courmont'
Cc: [email-masked]
Subject: RE: [Sipping] sipping-nat-scenarios section 3.2.1 symmetricRTP:betterguidance?

-d

Information contained in this e-mail and any attachments are intended for the use of the addressee only, and may contain confidential information of Ubiquity Software Corporation. All unauthorized use, disclosure or distribution is strictly prohibited.  If you are not the addressee, please notify the sender immediately and destroy all copies of this email. Ubiquity Software Corporation plc, a company registered under the laws of England and Wales, Registration 2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.