Subject: [BEHAVE] Outbound and SPI

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 01 Feb 2007 16:05:42 -0700

I ran into an interesting problem today while testing with a user.  
While multiplexing STUN over the SIP port, it became apparent that the 
Stateful Packet Inspection (SPI) in a very popular widely sold 
NAT/Firewall router that shall remain nameless was blocking the SIP 
responses.  Won't such behaviour be a problem for the outbound draft 
that calls for this multiplexing too.  Has anyone else seen this 
behavior?  It appears that the router wants STUN on the STUN port and 
SIP on the SIP port.  What do we do about this wrt multiplexing?

Thanks,
FM

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 1 Feb 2007 15:28:27 -0800

(CC'ing sip and the authors of sip-outbound)

That couldn't have been an enjoyable way to have spent a few hours of your
day.  That NAT isn't compliant with BEHAVE, of course, which requires that
such application awareness be turned off for UDP protocols.  For exactly
this reason!

In order to deal with such a NAT with its application layer gateway (SPI)
turned on, it might be prudent for sip-outbound to discuss verifying such a
middlebox isn't dropping STUN packets on UDP/5060.  For example,
sip-outbound could encourage a SIP UA to revert to a less appealing
keepalive mechanism if the initial STUN Binding Request messages don't
result in STUN Binding Response messages.

I expect that same SPI would have dropped the PING method, so it might not
be useful to choose the PING method as the less-appealing keepalive
mechanism.  I expect you're stuck with ".<CR><LF>" or frequent re-Register
to get around such a NAT, but I'll leave that for others to decide.

-d

> -----Original Message-----
> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Thursday, February 01, 2007 3:06 PM
> To: [email-masked]
> Subject: [BEHAVE] Outbound and SPI
> 
>

---

From: "Frank W. Miller" <[email-masked]>
Date: Thu, 01 Feb 2007 16:45:40 -0700

I'm interested in the responses from others.  I will say this quickly.  
I suggested just turning it off but the user I was working with has a 
static IP address and therefore considers SPI very important as a 
mechanism to deny DoS attacks.  I am wondering whether disallowing SPI 
for UDP is going to be realistic?

Again, this is a very widely available NAT router that come with SPI 
turned on by default it appears.  I also checked whether the router was 
tested in the draft you mentioned and its not best as I read the draft.  
I'll cc you personally with the specific router equipment if you're 
interested.  I just don't think its fair to name equipment makers on the 
public list.

Thanks,
FM

Dan Wing wrote:
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>
>

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 2 Feb 2007 07:44:23 -0800

Frank,

I'm curious if this product interferes with SIP over TCP traffic.  Did 
you try this out by any chance?

thanks,
-rohan

On Feb 1, 2007, at 15:45, Frank W. Miller wrote:
> turned on by default it appears.  I also checked whether the router 
> was tested in the draft you mentioned and its not best as I read the 
> draft.  I'll cc you personally with the specific router equipment if 
> you're interested.  I just don't think its fair to name equipment 
> makers on the public list.
>
> Thanks,
> FM
>
>
> Dan Wing wrote:
>>> From: Frank W. Miller [mailto:[email-masked]] Sent: Thursday, 
>>> February 01, 2007 3:06 PM
>>> To: [email-masked]
>>> While multiplexing STUN over the SIP port, it became apparent that 
>>> the Stateful Packet Inspection (SPI) in a very popular widely sold 
>>> behavior?  It appears that the router wants STUN on the STUN port 
>>> and SIP on the SIP port.  What do we do about this wrt multiplexing?
>>>
>>> Thanks,
>>> FM
>>>
>>>

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 02 Feb 2007 08:54:13 -0700

Uh, new client, don't have TCP transport in yet.  Fortunately, the user 
is someone I know so I'll be able to test it once its in.

FM

Rohan Mahy wrote:
>> I'm interested in the responses from others.  I will say this 
>> quickly.  I suggested just turning it off but the user I was working 
>> with has a static IP address and therefore considers SPI very 
>> important as a mechanism to deny DoS attacks.  I am wondering whether 
>> disallowing SPI for UDP is going to be realistic?
>>
>>>> responses.  Won't such behaviour be a problem for the outbound 
>>>> draft that calls for this multiplexing too.  Has anyone else seen 
>>>> this behavior?  It appears that the router wants STUN on the STUN 
>>>> port and SIP on the SIP port.  What do we do about this wrt 
>>>> multiplexing?
>>>>
>>>> Thanks,
>>>> FM
>>>>
>>>>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 4 Feb 2007 21:36:20 -0800

> >>>> port and SIP on the SIP port.  What do we do about this wrt

Well, this is exactly the kind of behavior that drove inclusion of an
obfuscation mechanism in the STUN response. Some NAT tend to be
hyperactive. The proper solution is probably to obfuscate the entire SIP
traffic. Running SIP over TLS does it nicely, but if we insist on UDP,
we may need to ask the SIP group to define an encrypted transport.

By the way, SPI may or may not improve the security of your network. SPI
requires that the router parse a lot of different packets, in order to
find possible attacks and protocol violation. Parsing code is a
notorious source of bugs. There are multiple examples of maliciously
crafted packets triggering a buffer overflow in a speedily written
parser. There is also some evidence that the quality of code in many of
these small routers is not great -- otherwise, we would not need to
reboot them so often. SPI on a small router brings the combination of
"lots of parsing code" with "questionable quality assurance". Turning on
SPI in the router may well be building a bright target for hackers just
at the doorstep of your network...

-- Christian Huitema

---

From: "David Barrett" <[email-masked]>
Date: Sun, 4 Feb 2007 23:46:45 -0800

Do you have any data or estimate on how common this type of NAT is?

-david

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Sunday, February 04, 2007 9:36 PM
> To: Frank W. Miller; Rohan Mahy
> Cc: [email-masked]; Dan Wing
> Subject: RE: [Sip] RE: [BEHAVE] Outbound and SPI
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 5 Feb 2007 09:25:57 -0800

Christian Huitema wrote:

...
> Well, this is exactly the kind of behavior that drove inclusion of
> an obfuscation mechanism in the STUN response.  Some NAT tend to be
> hyperactive.  The proper solution is probably to obfuscate the
> entire SIP traffic.  Running SIP over TLS does it nicely, but if we
> insist on UDP, we may need to ask the SIP group to define an
> encrypted transport.

There is SIP-over-DTLS, draft-jennings-sip-dtls-02.txt (which has
expired).  Of course, continuing to run SIP over UDP only 
encourages the problems discussed in 
draft-heffner-frag-harmful-04.txt.

> By the way, SPI may or may not improve the security of your network.
> SPI requires that the router parse a lot of different packets, in
> order to find possible attacks and protocol violation.  Parsing code
> is a notorious source of bugs.  There are multiple examples of
> maliciously crafted packets triggering a buffer overflow in a
> speedily written parser.  There is also some evidence that the
> quality of code in many of these small routers is not great --
> otherwise, we would not need to reboot them so often.  SPI on a
> small router brings the combination of "lots of parsing code" with
> "questionable quality assurance".  Turning on SPI in the router may
> well be building a bright target for hackers just at the doorstep of
> your network...

I couldn't agree more.

-d

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 05 Feb 2007 09:12:25 -0600

Just curious...

From: "Christian Huitema" <[email-masked]>

"Well, this is exactly the kind of behavior that drove inclusion of an
obfuscation mechanism in the STUN response. Some NAT tend to be
hyperactive. The proper solution is probably to obfuscate the entire SIP
traffic. Running SIP over TLS does it nicely, but if we insist on UDP,
we may need to ask the SIP group to define an encrypted transport."

Christian is not the first person I've heard asserting that encrypting 
transport solved problems with "hyperactive NATs" (great term - is it in 
common use?).

Do we have a BCP underway anywhere that says "NATs SHOULD/MUST pass 
encrypted transport packets", with whatever qualifiers are appropriate?

If not, I'm concerned that next-generation NATs may close this "security 
hole" ("my gosh, someone is sending packets through my NAT and I don't know 
what they're doing"), leaving us at the next stage of the unending arms race 
with a really damaged network.

This may still happen, but at least we're not silent until it happens.

"By the way, SPI may or may not improve the security of your network. SPI
at the doorstep of your network..."

How could I disagree? It would be lovely if these "security" measures didn't 
make you LESS secure - sometimes "breaking even" is an improvement.

Thanks,

Spencer

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Feb 2007 13:01:55 -0600

I think we went through this already as part of ICE discussion
(therefore probably in MMUSIC).

Indeed the conclusion was that encryption was the solution (as 
opposed to obfuscating every single protocol element where one
can potentially screw-up).

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 07:12
> To: [email-masked]
> Subject: Re: [Sip] RE: [BEHAVE] Outbound and SPI
> 
> Just curious...
> 
> "Well, this is exactly the kind of behavior that drove 
> inclusion of an obfuscation mechanism in the STUN response. 
> Some NAT tend to be hyperactive. The proper solution is 
> probably to obfuscate the entire SIP traffic. Running SIP 
> over TLS does it nicely, but if we insist on UDP, we may need 
> to ask the SIP group to define an encrypted transport."
> 
> Christian is not the first person I've heard asserting that 
> encrypting transport solved problems with "hyperactive NATs" 
> (great term - is it in common use?).
> 
> Do we have a BCP underway anywhere that says "NATs 
> SHOULD/MUST pass encrypted transport packets", with whatever 
> qualifiers are appropriate?
> 
> If not, I'm concerned that next-generation NATs may close 
> this "security hole" ("my gosh, someone is sending packets 
> through my NAT and I don't know what they're doing"), leaving 
> us at the next stage of the unending arms race with a really 
> damaged network.
> 
> "By the way, SPI may or may not improve the security of your 
> network. SPI requires that the router parse a lot of 
> different packets, in order to find possible attacks and 
> protocol violation. Parsing code is a notorious source of 
> bugs. There are multiple examples of maliciously crafted 
> packets triggering a buffer overflow in a speedily written 
> parser. There is also some evidence that the quality of code 
> in many of these small routers is not great -- otherwise, we 
> would not need to reboot them so often. SPI on a small router 
> brings the combination of "lots of parsing code" with 
> "questionable quality assurance". Turning on SPI in the 
> router may well be building a bright target for hackers just 
> How could I disagree? It would be lovely if these "security" 
> measures didn't make you LESS secure - sometimes "breaking 
> even" is an improvement.
> 
> Thanks,
> 
> Spencer 
> 
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 5 Feb 2007 11:32:43 -0800

> Sent: Monday, February 05, 2007 7:12 AM
> To: [email-masked]
> entire SIP

No, we don't.  But it isn't necessary -- such a NAT wouldn't work
with your bank, stockbroker, HTTPS-based webmail, and so on, which
default to port 443.  It wouldn't work with STARTTLS-encrypted
email submission.  It wouldn't work with Skype.  It wouldn't work
with other things it "thinks" are encrypted (which are just new
things it doesn't understand).

Such a product would be a failure in the market.

> If not, I'm concerned that next-generation NATs may close this
> "security hole" ("my gosh, someone is sending packets through my NAT
> and I don't know what they're doing"), leaving us at the next stage
> of the unending arms race with a really damaged network.
> 

I'm not sure what we could say.  Afterall, there are legitimate
security policies (enforced with equipment available today) that
allows companies to provide content filtering of email, web, and
ftp traffic.  This is done to discourage employees from using
the comapny's network and computer resources for personal use
and to decrease the company's exposure to lawsuits.

But that stuff is beyond BEHAVE's scope, and I expect beyond
IETF's scope.

-d

> network. SPI
> in many of
> measures didn't