Two patches for nf_conntrack_sip

Two patches for nf_conntrack_sip

[Greg Alexander]

Hello fellow hackers -

I uncovered some issues with net/netfilter/nf_conntrack_sip.c while using
my softphone across a Linux NAT gateway.  I am using Linux 2.6.27.37, so
I hope that this email is still pertinent!  Since I don't know how we
feel about attachments here, I've put the three patches at:
   http://galexander.org/nf_sip/patch1
   http://galexander.org/nf_sip/patch2

And in case you don't bother reading the rest of the email, I want to say
thank you!!  to all of the people who made this system work.  It is a
little frustrating to have to debug it but the quantity and quality of
work that went into it is obvious.  It is great that I get to submit two
one-character patches and pretend that I'm saving the day. :)


patch1 is an off-by-one.  It broke most translation on compact SIP
headers.  In a string like "v:SIP/2.0..." it was checking for
!isalpha('S') when it meant to be inspecting the ':'.


patch2 changes the default for "sip_direct_media" value.

A little detail about SIP (RFC3261).  SIP is a protocol for interacting
with a network of proxies to initiate a direct connection with another
party, whose IP address you do not know at the beginning of the
transaction. Each party sends their IP address/port number to the other
through SIP. As I understand it, we only track one side (outgoing) of the
SIP conversation, so we do not know the address/port that the other party
will be using.

When sip_direct_media is true, it assumes that the remote party's IP
address is the same as the address of the SIP proxy we have been
communicating with.  This is wrong, and will almost never work, as the
explicit purpose of SIP is to use a proxy to determine the location of a
remote peer -- the scenarios where they are at the same IP address are
almost inconceivable.

When sip_direct_media is false, it makes no assumptions about the remote
party's IP.  In general I think it will find the next packet that comes
in to the correct destination port (the one in the expect record) and
then use the associated source IP/port for the NAT. This is also wrong,
but less so.  It allows someone who is snooping the traffic to hijack the
connection (though you could argue once someone has that level of access,
the game is up anyways).  There may also be one other disadvantage...I do
not understand netfilter well enough to say with certainty what would
happen if two connections originated at about the same time that
attempted to use the same source UDP port.  It seems like there's at
least the possibility for a race condition that would result in the
streams being crossed.

On balance, sip_direct_media=0 is better than 1 because it works in a far
greater number of scenarios and requires either a large volume of traffic
or a coordinated attack to show any downsides.  My patch changes the
default to 0.

The correct answer of course is to observe both sides of the SIP dialogue
and precisely match the source address as well as the destination address
of the expected packet.  I'd like to see this happen.  I'm not sure I'm
volunteering because even if I find the time, someone would probably have
to clean up after me because I'm just not terribly familiar with
netfilter idioms.


An observation about SIP failure modes.  I have the impression that
nf_conntrack_sip almost never intervenes successfully.  With my
particular phone/provider, it manifest in being able to receive calls but
not place them.  It turns out this is because my telco uses two totally
different servers for incoming and outgoing calls.  Coincidentally, the
one that is used for outgoing calls blindly sends media packets to the
address that I tell it to.  However, the one that is used for incoming
calls is specifically aware of broken NAT and sends messages to the UDP
port that you send from, regardless of what packet was specified in the
header.  In effect, they ignore the port number that is specified in the
SIP transaction because it is so often wrong (due to NAT).

The point is that when a user reports that nf_nat_sip/nf_conntrack_sip
behave in an unpredictable way, it is likely because nf_nat_sip is
consistently not working and the user is interacting with a variety of
peers, some of whom silently adjust for broken NAT and others of which do
not.


Thanks!
- Greg

Re: Two patches for nf_conntrack_sip

[Patrick McHardy]

Greg Alexander wrote:
> Hello fellow hackers -
> 
> I uncovered some issues with net/netfilter/nf_conntrack_sip.c while using
> my softphone across a Linux NAT gateway.  I am using Linux 2.6.27.37, so
> I hope that this email is still pertinent!  Since I don't know how we
> feel about attachments here, I've put the three patches at:
>    http://galexander.org/nf_sip/patch1
>    http://galexander.org/nf_sip/patch2

Please always attach patches you want to submit.

> And in case you don't bother reading the rest of the email, I want to say
> thank you!!  to all of the people who made this system work.  It is a
> little frustrating to have to debug it but the quantity and quality of
> work that went into it is obvious.  It is great that I get to submit two
> one-character patches and pretend that I'm saving the day. :)
> 
> 
> patch1 is an off-by-one.  It broke most translation on compact SIP
> headers.  In a string like "v:SIP/2.0..." it was checking for
> !isalpha('S') when it meant to be inspecting the ':'.

Good catch. IIRC the client I used for testing uses "v:<space>...",
so it still worked properly.

> patch2 changes the default for "sip_direct_media" value.
> 
> A little detail about SIP (RFC3261).  SIP is a protocol for interacting
> with a network of proxies to initiate a direct connection with another
> party, whose IP address you do not know at the beginning of the
> transaction. Each party sends their IP address/port number to the other
> through SIP. As I understand it, we only track one side (outgoing) of the
> SIP conversation, so we do not know the address/port that the other party
> will be using.
> 
> When sip_direct_media is true, it assumes that the remote party's IP
> address is the same as the address of the SIP proxy we have been
> communicating with.  This is wrong, and will almost never work, as the
> explicit purpose of SIP is to use a proxy to determine the location of a
> remote peer -- the scenarios where they are at the same IP address are
> almost inconceivable.

Well, it depends, there are a lot of setups where the registrar is
also proxying RTP. But the main reason why this defaults to 1 is
because netfilter usually doesn't allow expectations for addresses
not belonging to the connection since that allows to poke holes to
arbitrary peers into the firewall. So people should think before they
enable this and adjust their ruleset to restrict this as far as
possible.

> When sip_direct_media is false, it makes no assumptions about the remote
> party's IP.  In general I think it will find the next packet that comes
> in to the correct destination port (the one in the expect record) and
> then use the associated source IP/port for the NAT. This is also wrong,
> but less so.

Actually it is correct in my understanding since early media can arrive
before the remote SDP address is even known.

> It allows someone who is snooping the traffic to hijack the
> connection (though you could argue once someone has that level of access,
> the game is up anyways).  There may also be one other disadvantage...I do
> not understand netfilter well enough to say with certainty what would
> happen if two connections originated at about the same time that
> attempted to use the same source UDP port.  It seems like there's at
> least the possibility for a race condition that would result in the
> streams being crossed.
> 
> On balance, sip_direct_media=0 is better than 1 because it works in a far
> greater number of scenarios and requires either a large volume of traffic
> or a coordinated attack to show any downsides.  My patch changes the
> default to 0.
> 
> The correct answer of course is to observe both sides of the SIP dialogue
> and precisely match the source address as well as the destination address
> of the expected packet.  I'd like to see this happen.  I'm not sure I'm
> volunteering because even if I find the time, someone would probably have
> to clean up after me because I'm just not terribly familiar with
> netfilter idioms.

Thats unfortunately not possible with early media.

> An observation about SIP failure modes.  I have the impression that
> nf_conntrack_sip almost never intervenes successfully.  With my
> particular phone/provider, it manifest in being able to receive calls but
> not place them.  It turns out this is because my telco uses two totally
> different servers for incoming and outgoing calls.  Coincidentally, the
> one that is used for outgoing calls blindly sends media packets to the
> address that I tell it to.  However, the one that is used for incoming
> calls is specifically aware of broken NAT and sends messages to the UDP
> port that you send from, regardless of what packet was specified in the
> header.  In effect, they ignore the port number that is specified in the
> SIP transaction because it is so often wrong (due to NAT).

That's usually caused by your client inserting headers that are not
translated, making the remote side aware that the peer is behind a NAT
and enabling workarounds. Have a look at the outgoing packets and look
for untranslated addresses or port numbers. Fixing those should fix this
behaviour.

> The point is that when a user reports that nf_nat_sip/nf_conntrack_sip
> behave in an unpredictable way, it is likely because nf_nat_sip is
> consistently not working and the user is interacting with a variety of
> peers, some of whom silently adjust for broken NAT and others of which do
> not.

Re: Two patches for nf_conntrack_sip

[Greg Alexander]

Thank you for your response.

> Well, it depends, there are a lot of setups where the registrar is
> also proxying RTP. But the main reason why this defaults to 1 is
> because netfilter usually doesn't allow expectations for addresses
> not belonging to the connection since that allows to poke holes to
> arbitrary peers into the firewall. So people should think before they
> enable this and adjust their ruleset to restrict this as far as
> possible.

I agree that it has a potential to be a minor security risk.  However,
the entire point of NAT is to allow packets through a firewall.  If an
interior host signals that it wants to accept foreign packets on a port,
NAT should not hamper him from it.

This is a very prominent problem.  Search google: people everywhere are
whining about this, though most of them don't know the cause.
sip_direct_media=1 simply does not work with the majority of common SIP
scenarios and does not conform to the standard.  We have three options:
(A) unsatisying user experience, (b) informing every noob that they need
to set sip_direct_media=0 for their phone to work, or (C) fixing the
default. Option (A) rules supreme today.

Should defaults reflect the most secure possible setting, or should they
reflect the most commonly-used setting?  We can have the best of both
worlds, as the default is to leave nf_conntrack_sip/nf_nat_sip out of the
kernel entirely -- secure wins by default.  Any user who goes to the
effort to include these modules does so because they want their NAT to be
able to handle SIP connections.  My SIP-conforming device opens a UDP
socket and accepts packets from *.*.*.*:* so I don't see why my
SIP-conforming NAT wouldn't also accept packets from *.*.*.*:*.

And thanks for informing me of early media.  I was not aware SIP would
allow that, but it makes sense since really only one side of the
conversation really needs to provide an SDP anyways.

> > An observation about SIP failure modes.  I have the impression that
> > nf_conntrack_sip almost never intervenes successfully.  With my
> > particular phone/provider, it manifest in being able to receive calls but
> > not place them.  It turns out this is because my telco uses two totally
> > different servers for incoming and outgoing calls.  Coincidentally, the
> > one that is used for outgoing calls blindly sends media packets to the
> > address that I tell it to.  However, the one that is used for incoming
> > calls is specifically aware of broken NAT and sends messages to the UDP
> > port that you send from, regardless of what packet was specified in the
> > header.  In effect, they ignore the port number that is specified in the
> > SIP transaction because it is so often wrong (due to NAT).
> 
> That's usually caused by your client inserting headers that are not
> translated, making the remote side aware that the peer is behind a NAT
> and enabling workarounds. Have a look at the outgoing packets and look
> for untranslated addresses or port numbers. Fixing those should fix this
> behaviour.

Fixing those was the first thing I did and is what resulted in the
off-by-one patch to handle compact SIP.  I think you may not be aware of
this particular hack, so I will explain it in more detail.  With
sip_direct_media=1 this is what happens.

When I receive an incoming call, I get an SDP payload indicating I am to
exchange media with hostA:portA, and I send an SDP payload indicating I
am at hostB:portB.  hostB:portB in this case happens to be correct on the
external interface (the nat mapping is correct), the only trouble is that
the conntrack expectation is for the SIP host instead of hostA.

So the RTP streams on the external interface look like this:
   hostA:portA -> hostB:portB - doesn't match expect, ignored by NAT (dropped)
   hostB:1024 -> hostA:portA - doesn't match expect, default NAT mapping
              gets port 1024 instead of portB.
   hostA:portA -> hostB:1024 - remote host has detected that I am not using
              portB, and silently switched ports
   hostB:1024 -> hostA:portA
   hostA:portA -> hostB:1024 ... the communication proceeds correctly

However for outgoing calls, the remote SDP uses a different hostA at a
different data center, and that conversation goes like this:
   hostA:portA -> hostB:portB - doesn't match expect, dropped
   hostB:1024 -> hostA:portA - port 1024 instead of portB
   hostA:portA -> hostB:portB
   hostB:1024 -> hostA:portA ....
Since the remote host is always sending to portB while NAT has assigned
me 1024 by default, one side of the conversation is dropped.

This is a result of sip_direct_media=1 interacting with two different
remote RTP peer implementations, even after all of the SIP/SDP fields
have been correctly modified by nf_nat_sip.  In the first case, the
connection works even though the sip_direct_media=1 setting is wrong for
my scenario.  If you want, I can send you URLs for many threads containing
end-user complaints that exactly match this scenario, most of which went
unresolved.  I am using Gizmo5, which is quite popular.

Thanks!

- Greg

Re: Two patches for nf_conntrack_sip

[Patrick McHardy]

Greg Alexander wrote:
> Thank you for your response.
> 
>> Well, it depends, there are a lot of setups where the registrar is
>> also proxying RTP. But the main reason why this defaults to 1 is
>> because netfilter usually doesn't allow expectations for addresses
>> not belonging to the connection since that allows to poke holes to
>> arbitrary peers into the firewall. So people should think before they
>> enable this and adjust their ruleset to restrict this as far as
>> possible.
> 
> I agree that it has a potential to be a minor security risk.  However,
> the entire point of NAT is to allow packets through a firewall.  If an
> interior host signals that it wants to accept foreign packets on a port,
> NAT should not hamper him from it.

No, NAT is only responsible for address translation, and in fact it
isn't even involved in this decision. The connection tracking helper
(which can also be used without NAT) creates expectations, the expected
connections have to be permitted by the ruleset. The helper doesn't
drop or allow anything, all this parameter does is control how the
expectations are set up (wildcards or no wildcards).

> This is a very prominent problem.  Search google: people everywhere are
> whining about this, though most of them don't know the cause.
> sip_direct_media=1 simply does not work with the majority of common SIP
> scenarios and does not conform to the standard.  We have three options:
> (A) unsatisying user experience, (b) informing every noob that they need
> to set sip_direct_media=0 for their phone to work, or (C) fixing the
> default. Option (A) rules supreme today.

I've seen quite a few of those bug reports myself, and in all but one
case it was actually people using the old version of the helper, which
didn't work properly at all (and didn't support these parameters).

> Should defaults reflect the most secure possible setting, or should they
> reflect the most commonly-used setting?  We can have the best of both
> worlds, as the default is to leave nf_conntrack_sip/nf_nat_sip out of the
> kernel entirely -- secure wins by default.  Any user who goes to the
> effort to include these modules does so because they want their NAT to be
> able to handle SIP connections.  My SIP-conforming device opens a UDP
> socket and accepts packets from *.*.*.*:* so I don't see why my
> SIP-conforming NAT wouldn't also accept packets from *.*.*.*:*.

Mainly because conntrack helpers track all connections to a specific
port, so without taking care, people can easily circumvent your ruleset.
If SIP tracking would be configured for specific registrar I'd probably
have used the more permissive mode by default, but unfortunately this is
not how conntrack works.

> And thanks for informing me of early media.  I was not aware SIP would
> allow that, but it makes sense since really only one side of the
> conversation really needs to provide an SDP anyways.
> 
>>> An observation about SIP failure modes.  I have the impression that
>>> nf_conntrack_sip almost never intervenes successfully.  With my
>>> particular phone/provider, it manifest in being able to receive calls but
>>> not place them.  It turns out this is because my telco uses two totally
>>> different servers for incoming and outgoing calls.  Coincidentally, the
>>> one that is used for outgoing calls blindly sends media packets to the
>>> address that I tell it to.  However, the one that is used for incoming
>>> calls is specifically aware of broken NAT and sends messages to the UDP
>>> port that you send from, regardless of what packet was specified in the
>>> header.  In effect, they ignore the port number that is specified in the
>>> SIP transaction because it is so often wrong (due to NAT).
>> That's usually caused by your client inserting headers that are not
>> translated, making the remote side aware that the peer is behind a NAT
>> and enabling workarounds. Have a look at the outgoing packets and look
>> for untranslated addresses or port numbers. Fixing those should fix this
>> behaviour.
> 
> Fixing those was the first thing I did and is what resulted in the
> off-by-one patch to handle compact SIP.  I think you may not be aware of
> this particular hack, so I will explain it in more detail.  With
> sip_direct_media=1 this is what happens.
> 
> When I receive an incoming call, I get an SDP payload indicating I am to
> exchange media with hostA:portA, and I send an SDP payload indicating I
> am at hostB:portB.  hostB:portB in this case happens to be correct on the
> external interface (the nat mapping is correct), the only trouble is that
> the conntrack expectation is for the SIP host instead of hostA.
> 
> So the RTP streams on the external interface look like this:
>    hostA:portA -> hostB:portB - doesn't match expect, ignored by NAT (dropped)
>    hostB:1024 -> hostA:portA - doesn't match expect, default NAT mapping
>               gets port 1024 instead of portB.
>    hostA:portA -> hostB:1024 - remote host has detected that I am not using
>               portB, and silently switched ports
>    hostB:1024 -> hostA:portA
>    hostA:portA -> hostB:1024 ... the communication proceeds correctly
> 
> However for outgoing calls, the remote SDP uses a different hostA at a
> different data center, and that conversation goes like this:
>    hostA:portA -> hostB:portB - doesn't match expect, dropped
>    hostB:1024 -> hostA:portA - port 1024 instead of portB
>    hostA:portA -> hostB:portB
>    hostB:1024 -> hostA:portA ....
> Since the remote host is always sending to portB while NAT has assigned
> me 1024 by default, one side of the conversation is dropped.
> 
> This is a result of sip_direct_media=1 interacting with two different
> remote RTP peer implementations, even after all of the SIP/SDP fields
> have been correctly modified by nf_nat_sip.  In the first case, the
> connection works even though the sip_direct_media=1 setting is wrong for
> my scenario.  If you want, I can send you URLs for many threads containing
> end-user complaints that exactly match this scenario, most of which went
> unresolved.  I am using Gizmo5, which is quite popular.

So does it work with sip_direct_media=0?

Re: Two patches for nf_conntrack_sip

[Greg Alexander]

On Mon, Jan 18, 2010 at 07:13:59PM +0100, Patrick McHardy wrote:
> No, NAT is only responsible for address translation, and in fact it
> isn't even involved in this decision. The connection tracking helper
> (which can also be used without NAT) creates expectations, the expected
> connections have to be permitted by the ruleset. The helper doesn't
> drop or allow anything, all this parameter does is control how the
> expectations are set up (wildcards or no wildcards).

The thing is, you don't even need to violate the separation between NAT
and conntrack.  You are arguing that conntrack is only supposed to track
connections, and you seem to believe that a connection exists only when
both ends have been fully specified.  Wildcard addresses do violate that
definition, but that definition is unduly limited.

There is a type of connection in which one endpoint is unspecified until
after traffic is received.  In TCP, this is a listen socket used for
peer-to-peer communication, like IRC's DCC.  Rightfully we do not love
such wildcard connection strategies, but we acknowledge that we are not
the body that forms the standards.  Thus nf_nat_irc is born.  SIP/SDP
uses the same connection strategy (at least if early media is in play).

The actual exposure from this wildcard is very limited.  We only open the
port when the internal host specifically requests it, and ultimately the
expectation is only in effect for the first remote host to trigger it.
The worst case scenario would be to allow people to send arbitrary
packets to a port that is expecting valid media data.  This isn't great
but it's a weakness imposed by the protocol.  As a bonus, the softphone
software has access to both the SDP stream and the original source
address on these UDP packets, so it can make its own decisions (generally
turning it into a DoS instead of compromise).

> I've seen quite a few of those bug reports myself, and in all but one
> case it was actually people using the old version of the helper, which
> didn't work properly at all (and didn't support these parameters).

Maybe I'm misunderstanding the epidemiology here, but don't you see
yourself sending out "try sip_direct_media=0" to each and every person
who contacts you?  Just imagine the thousands (soon millions) of users
who would benefit from sip_direct_media=0 who will not know to contact
you?  The Linux kernel is packaged in most routers these days. It's all
fine and dandy to force Linksys to add "sip_direct_media=0" to their
options, but from the user perspective this option should be called
"break_big_sip_providers=0".  I don't think I would be willing to blame
D-Link for failing to anticipate that we would provide a
"break_big_sip_providers" option which defaults to 1.  Even now, but
especially in the future, SIP usage will be dominated by big providers.
Gizmo5 is soon to be pronounced "Google Voice." I'd understand a quixotic
desire to break common practice so that we can enforce a standard, but
the standard in this case is clear that we are in violation, not the
commercial providers.

I mean, are we really in the business of distributing the "works with
Asterisk" standards-ignoring but-slightly-safer SIP translator?

> So does it work with sip_direct_media=0?

Yes, it works perfectly with sip_direct_media=0.

Thanks,
- Greg

Re: Two patches for nf_conntrack_sip

[Patrick McHardy]

Greg Alexander wrote:
> On Mon, Jan 18, 2010 at 07:13:59PM +0100, Patrick McHardy wrote:
>> No, NAT is only responsible for address translation, and in fact it
>> isn't even involved in this decision. The connection tracking helper
>> (which can also be used without NAT) creates expectations, the expected
>> connections have to be permitted by the ruleset. The helper doesn't
>> drop or allow anything, all this parameter does is control how the
>> expectations are set up (wildcards or no wildcards).
> 
> The thing is, you don't even need to violate the separation between NAT
> and conntrack.  You are arguing that conntrack is only supposed to track
> connections, and you seem to believe that a connection exists only when
> both ends have been fully specified.  Wildcard addresses do violate that
> definition, but that definition is unduly limited.
> 
> There is a type of connection in which one endpoint is unspecified until
> after traffic is received.  In TCP, this is a listen socket used for
> peer-to-peer communication, like IRC's DCC.  Rightfully we do not love
> such wildcard connection strategies, but we acknowledge that we are not
> the body that forms the standards.  Thus nf_nat_irc is born.  SIP/SDP
> uses the same connection strategy (at least if early media is in play).
> 
> The actual exposure from this wildcard is very limited.  We only open the
> port when the internal host specifically requests it, and ultimately the
> expectation is only in effect for the first remote host to trigger it.
> The worst case scenario would be to allow people to send arbitrary
> packets to a port that is expecting valid media data.  This isn't great
> but it's a weakness imposed by the protocol.  As a bonus, the softphone
> software has access to both the SDP stream and the original source
> address on these UDP packets, so it can make its own decisions (generally
> turning it into a DoS instead of compromise).

Its not about what applications or phones do at all. Its about what
you can do by sending fake INVITE or other requests containing foreign
addresses. I'm not going to change the default, sorry.

I'm working on supporting helpers for selected connections (using an
iptables target) however, for which I might reconsider this.

>> I've seen quite a few of those bug reports myself, and in all but one
>> case it was actually people using the old version of the helper, which
>> didn't work properly at all (and didn't support these parameters).
> 
> Maybe I'm misunderstanding the epidemiology here, but don't you see
> yourself sending out "try sip_direct_media=0" to each and every person
> who contacts you?  Just imagine the thousands (soon millions) of users
> who would benefit from sip_direct_media=0 who will not know to contact
> you?  The Linux kernel is packaged in most routers these days. It's all
> fine and dandy to force Linksys to add "sip_direct_media=0" to their
> options, but from the user perspective this option should be called
> "break_big_sip_providers=0".  I don't think I would be willing to blame
> D-Link for failing to anticipate that we would provide a
> "break_big_sip_providers" option which defaults to 1.  Even now, but
> especially in the future, SIP usage will be dominated by big providers.
> Gizmo5 is soon to be pronounced "Google Voice." I'd understand a quixotic
> desire to break common practice so that we can enforce a standard, but
> the standard in this case is clear that we are in violation, not the
> commercial providers.
> 
> I mean, are we really in the business of distributing the "works with
> Asterisk" standards-ignoring but-slightly-safer SIP translator?

This is a documentation question.

Its BTW completely in line with what other helpers do, we also
have a "gkrouted_only" option in H.323 defaulting to 1 and a
"loose" option in FTP for FXP, defaulting to 0. Both for exactly
the same reason.

>> So does it work with sip_direct_media=0?
> 
> Yes, it works perfectly with sip_direct_media=0.

Great. Could you send me the off-by-one fix please?

(PATCH) Re: Two patches for nf_conntrack_sip

[Greg Alexander]

> Its not about what applications or phones do at all. Its about what
> you can do by sending fake INVITE or other requests containing foreign
> addresses. I'm not going to change the default, sorry.

Okay, this is becoming increasingly frustrating for me.  I keep on
pointing out to you that SIP is a standard by which people register their
intent to exchange media streams directly between unrelated peers. You
then wave your hands and say "fake" or "poke a hole" and ignore what I've
said.  Nothing in nf_nat_sip permits arbitrary holes to be poked!  Until
the host initiates a SIP conversation, nf_nat_sip does not facilitate ANY
packets moving through the firewall.  Until the host sends an SDP packet,
nf_nat_sip only facilitates SIP packets.  Once the media stream begins,
nf_nat_sip will not facilitate any new holes without a new SDP packet.

An SDP packet is a conspicuous standard-conforming notification that
incoming traffic is expected on a specific local port, and the remote
host is left unspecified.  You are saying we should ignore this
standard-conforming notification merely because we do not approve of
wildcard remote hosts.  This is insufficient.  We only disapprove of
wildcard remote hosts because there is the potential to poke arbitrary
holes through the firewall.  There is the potential for monsters under my
bed, so I shine my flashlight and I know there are no monsters.  I
inspect nf_conntrack_sip and I know there is no arbitrary hole poking!

Your "no wildcard expectations" is a reasonable heuristic, or rule of
thumb.  And like any rule of thumb, it is to be discarded in favor of a
more thorough analysis whenever it turns out to be dysfunctional.

> I'm working on supporting helpers for selected connections (using an
> iptables target) however, for which I might reconsider this.

Um, I'm going to reiterate to you that the host _MUST REGISTER_ before
nf_nat_sip has any effect on them.  The idea of requiring an extra layer
of selection is meaningless extravagance.  If a host talks SIP on the
specified port, select them.  If they don't talk SIP, leave them alone.

> This is a documentation question.

The undocumented fact here is that you're breaking behavior for a huge
number of users and ultimately forcing SIP providers to break the
standard to communicate with users behind Linux NAT.  We should conform
with standards, not force others to break the standards!

> Its BTW completely in line with what other helpers do, we also
> have a "gkrouted_only" option in H.323 defaulting to 1 and a
> "loose" option in FTP for FXP, defaulting to 0. Both for exactly
> the same reason.

No one is astonished to learn that nf_nat_ftp doesn't support FXP.

I've cited nf_nat_irc.  It seems there's in fact precedent for each side.
Are you going to break nf_nat_irc now that I've brought it to your
attention?

> Great. Could you send me the off-by-one fix please?

You have some standards that you demand people adhere to.  You like
tcpdumps as binary attachments, and patches as text/plain.  Standards
make life easy, right?  There is no reason to even be flexible with
people when you can demand that they adhere to a reasonable standard.  I
like standards too.  I'm honoured by the opportunity to communicate with
you by adopting some of your standards.

SIP is a published standard that exists to allow direct media transfer
between two hosts who did not know or trust eachother at the beginning of
the transaction. Conform please.

I will escalate this disagreement because you are simply being stubborn
about something that is of no consequence to you based on the
misapplication of an overly general principle.  I assume at some point in
your life you've dealt with religious nuts who would not accept anything
you say because they have an authoritative source (the bible).  Well, I
have an authoritative source: RFC3261.  Until you give some good reason
for the Linux kernel to ignore this standard, I'm going to keep on
thumping that RFC.

I think you will find that standard adherence is a popular religion in
the open source world.

Patch follows.

Thanks!  (and I mean it -- apart from this one infelicity, your work is
very good!)

- Greg

--- nf_conntrack_sip.c	2010/01/15 21:51:08	1.1
+++ nf_conntrack_sip.c	2010/01/16 09:29:07	1.3
@@ -375,7 +375,7 @@
 			dptr += hdr->len;
 		else if (hdr->cname && limit - dptr >= hdr->clen + 1 &&
 			 strnicmp(dptr, hdr->cname, hdr->clen) == 0 &&
-			 !isalpha(*(dptr + hdr->clen + 1)))
+			 !isalpha(*(dptr + hdr->clen)))
 			dptr += hdr->clen;
 		else
 			continue;

Re: (PATCH) Re: Two patches for nf_conntrack_sip

[Patrick McHardy]

Greg Alexander wrote:
>> Its not about what applications or phones do at all. Its about what
>> you can do by sending fake INVITE or other requests containing foreign
>> addresses. I'm not going to change the default, sorry.
> 
> Okay, this is becoming increasingly frustrating for me.  I keep on
> pointing out to you that SIP is a standard by which people register their
> intent to exchange media streams directly between unrelated peers. You
> then wave your hands and say "fake" or "poke a hole" and ignore what I've
> said.  Nothing in nf_nat_sip permits arbitrary holes to be poked!  Until
> the host initiates a SIP conversation, nf_nat_sip does not facilitate ANY
> packets moving through the firewall.  Until the host sends an SDP packet,
> nf_nat_sip only facilitates SIP packets.  Once the media stream begins,
> nf_nat_sip will not facilitate any new holes without a new SDP packet.
> 
> An SDP packet is a conspicuous standard-conforming notification that
> incoming traffic is expected on a specific local port, and the remote
> host is left unspecified.  You are saying we should ignore this
> standard-conforming notification merely because we do not approve of
> wildcard remote hosts.  This is insufficient.  We only disapprove of
> wildcard remote hosts because there is the potential to poke arbitrary
> holes through the firewall.  There is the potential for monsters under my
> bed, so I shine my flashlight and I know there are no monsters.  I
> inspect nf_conntrack_sip and I know there is no arbitrary hole poking!

You obviously haven't inspected it very well. I have no interest in
continuing this debatte.

> Patch follows.
> 
> --- nf_conntrack_sip.c	2010/01/15 21:51:08	1.1
> +++ nf_conntrack_sip.c	2010/01/16 09:29:07	1.3
> @@ -375,7 +375,7 @@
>  			dptr += hdr->len;
>  		else if (hdr->cname && limit - dptr >= hdr->clen + 1 &&
>  			 strnicmp(dptr, hdr->cname, hdr->clen) == 0 &&
> -			 !isalpha(*(dptr + hdr->clen + 1)))
> +			 !isalpha(*(dptr + hdr->clen)))
>  			dptr += hdr->clen;
>  		else
>  			continue;

Applied, thanks.

Group consensus sought on nf_conntrack_sip behavior

[Greg Alexander]

Is there anyone else on this mailing list who cares to chime in?

I believe it is more important to conform to standards and common
practice, especially since they are the same in this case and present no
undue burden or risk.

Patrick McHardy seems to believe it is more important to enforce a rule
of thumb prohibiting wildcard expectations.

We each have precedent in other NAT helpers to support our position.

Any other opinions?  Linux is a group effort.

I'm not used to playing politics just to get a Linux project to adhere to
a standard, but here we are.  If I do not receive a satisfactory response
here, I will petition the non-development netfilter user list.  Should
that fail I will attempt to induce the vast masses of users who are
inconvenienced by this misfeature to write to various netfilter project
mailing lists.  Nip this in the bud, explain to me how sip_direct_media
poses an actual security risk worth breaking SIP NAT for most users over.

This issue will not go away for the userbase until the default is
changed.  The status quo in which the users are ignored is over.

Thanks,

- Greg

On Tue, Jan 19, 2010 at 07:09:18PM +0100, Patrick McHardy wrote:
> Greg Alexander wrote:
> >> Its not about what applications or phones do at all. Its about what
> >> you can do by sending fake INVITE or other requests containing foreign
> >> addresses. I'm not going to change the default, sorry.
> > 
> > Okay, this is becoming increasingly frustrating for me.  I keep on
> > pointing out to you that SIP is a standard by which people register their
> > intent to exchange media streams directly between unrelated peers. You
> > then wave your hands and say "fake" or "poke a hole" and ignore what I've
> > said.  Nothing in nf_nat_sip permits arbitrary holes to be poked!  Until
> > the host initiates a SIP conversation, nf_nat_sip does not facilitate ANY
> > packets moving through the firewall.  Until the host sends an SDP packet,
> > nf_nat_sip only facilitates SIP packets.  Once the media stream begins,
> > nf_nat_sip will not facilitate any new holes without a new SDP packet.
> > 
> > An SDP packet is a conspicuous standard-conforming notification that
> > incoming traffic is expected on a specific local port, and the remote
> > host is left unspecified.  You are saying we should ignore this
> > standard-conforming notification merely because we do not approve of
> > wildcard remote hosts.  This is insufficient.  We only disapprove of
> > wildcard remote hosts because there is the potential to poke arbitrary
> > holes through the firewall.  There is the potential for monsters under my
> > bed, so I shine my flashlight and I know there are no monsters.  I
> > inspect nf_conntrack_sip and I know there is no arbitrary hole poking!
> 
> You obviously haven't inspected it very well. I have no interest in
> continuing this debatte.
> 
> > Patch follows.
> > 
> > --- nf_conntrack_sip.c	2010/01/15 21:51:08	1.1
> > +++ nf_conntrack_sip.c	2010/01/16 09:29:07	1.3
> > @@ -375,7 +375,7 @@
> >  			dptr += hdr->len;
> >  		else if (hdr->cname && limit - dptr >= hdr->clen + 1 &&
> >  			 strnicmp(dptr, hdr->cname, hdr->clen) == 0 &&
> > -			 !isalpha(*(dptr + hdr->clen + 1)))
> > +			 !isalpha(*(dptr + hdr->clen)))
> >  			dptr += hdr->clen;
> >  		else
> >  			continue;
> 
> Applied, thanks.

Re: Group consensus sought on nf_conntrack_sip behavior

[Patrick McHardy]

Greg Alexander wrote:
> Is there anyone else on this mailing list who cares to chime in?
> 
> I believe it is more important to conform to standards and common
> practice, especially since they are the same in this case and present no
> undue burden or risk.
> 
> Patrick McHardy seems to believe it is more important to enforce a rule
> of thumb prohibiting wildcard expectations.
> 
> We each have precedent in other NAT helpers to support our position.

Well, I'll add one final point. You mentioned the IRC helper
as precedent, without referring to anything concrete. You're
mistaken though, the destination address is fixed. But I see
where your misunderstanding might come from.

What the SIP helper does is allow expectations between *arbitrary*
hosts when the direct_media option is off - the destination address
originates from the SDP payload, the source address is a wildcard.

> Any other opinions?  Linux is a group effort.
> 
> I'm not used to playing politics just to get a Linux project to adhere to
> a standard, but here we are.  If I do not receive a satisfactory response
> here, I will petition the non-development netfilter user list.  Should
> that fail I will attempt to induce the vast masses of users who are
> inconvenienced by this misfeature to write to various netfilter project
> mailing lists.  Nip this in the bud, explain to me how sip_direct_media
> poses an actual security risk worth breaking SIP NAT for most users over.
> 
> This issue will not go away for the userbase until the default is
> changed.  The status quo in which the users are ignored is over.
> 
> Thanks,

Have fun.

Re: Group consensus sought on nf_conntrack_sip behavior

[Greg Alexander]

On Tue, Jan 19, 2010 at 07:39:52PM +0100, Patrick McHardy wrote:
> Well, I'll add one final point. You mentioned the IRC helper
> as precedent, without referring to anything concrete. You're
> mistaken though, the destination address is fixed. But I see
> where your misunderstanding might come from.
> 
> What the SIP helper does is allow expectations between *arbitrary*
> hosts when the direct_media option is off - the destination address
> originates from the SDP payload, the source address is a wildcard.

*sigh*

I offered a DCC send from an internal host with nf_nat_irc:
  # cat /proc/net/ip_conntrack_expect
  289 proto=6 src=0.0.0.0 dst=98.223.156.20 sport=0 dport=4110
                  ^^^^^^^                         ^

I offered an RTP stream from an internal host using SIP/SDP with
nf_conntrack_sip sip_direct_media=0 (and nf_nat_sip of course):
  # cat /proc/net/ip_conntrack_expect
  179 proto=17 src=0.0.0.0 dst=98.223.156.20 sport=0 dport=7078
  179 proto=17 src=0.0.0.0 dst=98.223.156.20 sport=0 dport=7079
                   ^^^^^^^                         ^

The situations really are analogous and nf_nat_irc really does use a
wildcard for the remote end of the connection.  This is because both are
sloppy peer-to-peer protocols advertising over a proxy network using the
same handshaking methodology.

Oh and while we're on misinterpretations...I think maybe you thought I
was pushing for sip_direct_signalling=0.  I do not know if the standard
explicitly forbids indirect signalling, but personally I am a fan of
direct signalling, as are the major VOIP providers.  I think we would all
agree that sip_direct_signalling=0 presents a substantial risk for
nefarious activity.

Anyways, if you thought I was pushing for sip_direct_signalling=0 then it
makes sense that you would have figured I was insane.

- Greg


> 
> > Any other opinions?  Linux is a group effort.
> > 
> > I'm not used to playing politics just to get a Linux project to adhere to
> > a standard, but here we are.  If I do not receive a satisfactory response
> > here, I will petition the non-development netfilter user list.  Should
> > that fail I will attempt to induce the vast masses of users who are
> > inconvenienced by this misfeature to write to various netfilter project
> > mailing lists.  Nip this in the bud, explain to me how sip_direct_media
> > poses an actual security risk worth breaking SIP NAT for most users over.
> > 
> > This issue will not go away for the userbase until the default is
> > changed.  The status quo in which the users are ignored is over.
> > 
> > Thanks,
> 
> Have fun.

Re: Group consensus sought on nf_conntrack_sip behavior

[Patrick McHardy]

Greg Alexander wrote:
> On Tue, Jan 19, 2010 at 07:39:52PM +0100, Patrick McHardy wrote:
>> Well, I'll add one final point. You mentioned the IRC helper
>> as precedent, without referring to anything concrete. You're
>> mistaken though, the destination address is fixed. But I see
>> where your misunderstanding might come from.
>>
>> What the SIP helper does is allow expectations between *arbitrary*
>> hosts when the direct_media option is off - the destination address
>> originates from the SDP payload, the source address is a wildcard.
> 
> *sigh*
> 
> I offered a DCC send from an internal host with nf_nat_irc:
>   # cat /proc/net/ip_conntrack_expect
>   289 proto=6 src=0.0.0.0 dst=98.223.156.20 sport=0 dport=4110
>                   ^^^^^^^                         ^
> 
> I offered an RTP stream from an internal host using SIP/SDP with
> nf_conntrack_sip sip_direct_media=0 (and nf_nat_sip of course):
>   # cat /proc/net/ip_conntrack_expect
>   179 proto=17 src=0.0.0.0 dst=98.223.156.20 sport=0 dport=7078
>   179 proto=17 src=0.0.0.0 dst=98.223.156.20 sport=0 dport=7079
>                    ^^^^^^^                         ^

You are obviously unable to read. Why don't you go troll somewhere else.

RE: Group consensus sought on nf_conntrack_sip behavior

[Florian Fuessl]

Hi Patrick, Hi Greg,

as you know, the aspects of NAT have definitely not been considered on the
development of SIP (RFC 3261); so this topic has unfortunately much room for
discussions how to handle problematical issues in detail.

In fact, using SIP together with NAT is still a tricky pain requiring
uncomely workarounds (STUN, keepalive, ...) from the user side.

Nf_conntrack_sip has helped to reduce the issues of SIP with NAT a lot from
the user side; but beyond doubt there are still open traps and unsolved Bugs
requiring some review on the code in some cases. :-/

Patrick McHardy wrote:
> Greg Alexander wrote:
> > Is there anyone else on this mailing list who cares to chime in?
> >

I guess almost everyone on this list does not suffer from this problem
regarding no need for this code on the own "home" installation.

> > I believe it is more important to conform to standards and common
> > practice, especially since they are the same in this case and
> > present no undue burden or risk.
> >

Nf_conntrack_sip should conform to the standards as far as possible; but on
the other side - as it's enabled by default on many distros - it's required
not to open potential security holes on a default installation.

> > Patrick McHardy seems to believe it is more important to enforce a
> > rule of thumb prohibiting wildcard expectations.
> >
> > We each have precedent in other NAT helpers to support our position.
> 
> Well, I'll add one final point. You mentioned the IRC helper
> as precedent, without referring to anything concrete. You're
> mistaken though, the destination address is fixed. But I see
> where your misunderstanding might come from.
> 
> What the SIP helper does is allow expectations between *arbitrary*
> hosts when the direct_media option is off - the destination address
> originates from the SDP payload, the source address is a wildcard.
> 

IMHO the available options should be documented with examples requiring a
change of the default parameters.

Unfortunately using the default settings results in for most users hardly to
debug problems in some cases.

> > Any other opinions?  Linux is a group effort.
> >
> > [...]
> 
> Have fun.

sure: Yes, we have ;)

-Florian

Re: Group consensus sought on nf_conntrack_sip behavior

[Greg Alexander]

First off, you are undoubtedly correct that I did not interpret what you
were saying correctly.  But it is pointless to call me names.  Everyone
here already knows that you know more about netfilter than I do, there is
no point in using inflamatory language to make clear what was already
known.

I see now that there are two pairs of expectations set up (I only noticed
one before), and the current option controls both.  My intention was to
control only one of them, but that's not what the patch I suggested would
accomplish.  I was thus wrong, ignorant, and incorrect.  Surprised?
I'm not.

My intuition suggests that the ideal compromise is to split the
sip_direct_media option into two options, one controlling the incoming
media stream and the other controlling the outgoing media stream. This
could work well because it is very rare for the internal host to be a
pure SIP proxy (it is usually a client, no?) and it is very common for
the external host to be a pure SIP proxy (such as a telco). It provides
the possibility to allow arbitrary standard-conforming behavior by remote
peers without exposing any host on the internal network that doesn't
actually originate SIP packets.

I'm obviously going to have to learn more about how expectations are
converted into actual port forwarding assignments before I will be able to
make a more concrete recommendation.

Any comments are welcome as I embark on this quest.  Expect a patch
in a couple days.

- Greg
p.s., "troll" indicates a specific intention that does not apply here.
Perhaps you meant "ignoramus"?