stf, security and NAT traversal

[Rodolphe De Saint Leger]

Hi,

I've worked on a path for the stf interface to add more security and
nat traversal fonctionnality.

the new security features should have no visible impact, to activate
nat traversal, configure your future 6to4 router as the dmz of your
ipv4 network, and put the bit 49 of your prefix to 1.

for example:
ifconfig stf0 inet6 2002:5243:e682:c000::1 prefixlen 16

it will activate this 6to4 prefix with nat traversal. To emit a
packet, stf will search for the route to 82.67.230.130 and it will
take the outgoing local address as the ipv4 6to4 source.

Here is the link to the patch (and full file),
http://shumira.roroland.net/20080119/patch.diff
http://shumira.roroland.net/20080119/if_stf.c

Also, here is a little changelog. I've made tests to ensure that
current behavior is not impacted, could anyone review my code ?

I've made the following changes in the code :
- The bit 49 of the stf alias activates nat traversal for this alias
(no impact on routed packets)
- if nat is activated, the ipv4 address used is the source address
used to contact the external nat address,
- sanity check for ipv4 header is now done only in encap_check(),
- stf_getsrcifa4() returns a interface address which either match an
ipv4 incoming header, a ipv4 incoming address matching the 6to4
prefix, or the default outgoing ipv4 address,
- stf_output() now checks for invalid 6to4 packets (in case of
misconfiguration, bad packets will be dropped before going on wire),
- ingress filter has been added to ipv6 packets (it is disabled when needed).

Bad packets cases for output are the following :
- sending a 6to4 without any 6to4 address,
- sending a packet to our prefix (happen if we have no route to a
subnetwork in our 6to4 prefix),
- sending a packet to multicast/link local/compat/mapped address

Bad packets cases for input are the following :
- receiving a packet without any 6to4 address,
- receiving a packet that we can't route to any native interface (avoid bounce),
- receiving a 6to4 packet with a 6to4 src not matching ipv4 src

And sorry for my bad English.

Regards,
Rodolphe
--
int main(int c,char**v){int b,e=(c>>24)+6,g=c==1?1:e>>4;
char*d=c==1?"d3JpdGUgaW4gQw==":g==2?*v:v[c-1];b=c<<6|(*d
+(*d>96?-71:*d>58?-65:*d>47?4:*d>46?16:19));if(*d==61?0:
*d){if((e&=15)>7)putchar((b>>(e-=8))&255); d++;main(((e|
32)<<24)|(b&4095),&d);}return g<2&&c>2?main(--c,v):1;}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Rodolphe De Saint Leger
Hi,
I've worked on a path for the stf interface to add more security and
nat traversal fonctionnality.
the new security features should have no visible impact, to activate
nat traversal, configure your future 6to4 router as the dmz of your
ipv4 network, and put the bit 49 of your prefix to 1.
ifconfig stf0 inet6 2002:5243:e682:c000::1 prefixlen 16
it will activate this 6to4 prefix with nat traversal. To emit a
packet, stf will search for the route to 82.67.230.130 and it will
take the outgoing local address as the ipv4 6to4 source.
Here is the link to the patch (and full file),
http://shumira.roroland.net/20080119/patch.diff
http://shumira.roroland.net/20080119/if_stf.c
Also, here is a little changelog. I've made tests to ensure that
current behavior is not impacted, could anyone review my code ?
- The bit 49 of the stf alias activates nat traversal for this alias
(no impact on routed packets)
- if nat is activated, the ipv4 address used is the source address
used to contact the external nat address,
- sanity check for ipv4 header is now done only in encap_check(),
- stf_getsrcifa4() returns a interface address which either match an
ipv4 incoming header, a ipv4 incoming address matching the 6to4
prefix, or the default outgoing ipv4 address,
- stf_output() now checks for invalid 6to4 packets (in case of
misconfiguration, bad packets will be dropped before going on wire),
- ingress filter has been added to ipv6 packets (it is disabled when needed).
- sending a 6to4 without any 6to4 address,
- sending a packet to our prefix (happen if we have no route to a
subnetwork in our 6to4 prefix),
- sending a packet to multicast/link local/compat/mapped address
- receiving a packet without any 6to4 address,
- receiving a packet that we can't route to any native interface (avoid bounce),
- receiving a 6to4 packet with a 6to4 src not matching ipv4 src
And sorry for my bad English.
Regards,
Rodolphe

Can you send-pr this so that it does not get lost.

thanks,
christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Pavel Cahyna]

Post by Rodolphe De Saint Leger
Hi,
I've worked on a path for the stf interface to add more security and
nat traversal fonctionnality.
the new security features should have no visible impact, to activate
nat traversal, configure your future 6to4 router as the dmz of your
ipv4 network, and put the bit 49 of your prefix to 1.
ifconfig stf0 inet6 2002:5243:e682:c000::1 prefixlen 16
it will activate this 6to4 prefix with nat traversal. To emit a
packet, stf will search for the route to 82.67.230.130 and it will
take the outgoing local address as the ipv4 6to4 source.

Can you please describe in more detail what it is supposed to do and how
the network setup looks like? What are the problems you are trying to
solve?

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rodolphe De Saint Leger]

Post by Pavel Cahyna
Can you please describe in more detail what it is supposed to do and how
the network setup looks like? What are the problems you are trying to
solve?
Pavel

Actually, the stf interface does not check for misc cases which should
not come under nomal conditions. I've added some tests to ensure that
packets which try to abuse the 6to4 encapsulation gets dropped before
getting into the network. I tried to apply the security draft on 6to4.

my isp gives me a box which handles the ipv4 nat. This box don't know
about 6to4 encapsulation but you can configure a 'dmz host'. This host
will receive any incoming packet wich does not belong to an existing
nat session. let's say that my internal network is 192.168.7.0/24 and
the nat box has the internal address 192.168.7.1, the external address
82.67.230.130, and my 'dmz' netbsd has the address 192.168.7.2.

Actually you can make stf working by using a bimap rule, an alias on
lo0 and a trick in the routing table.

so with the actual stf inplementation this gives:
ifconfig stf0 create
ifconfig stf0 inet6 2002:5243:e682::1 prefixlen 16
ifconfig lo0 82.67.230.130 alias
/sbin/route delete 82.67.230.130
/sbin/route add 82.67.230.130 192.168.7.2

with the following bimap rule:
bimap vlan1 82.67.230.130/32 -> 192.168.7.2/32 ipv6

The patch adds also the ability for stf to emit/receive packets
directly on a internal interface, instead of using other kernels
subsystems (ipnat). With the patch applied, you just do:
ifconfig stf0 create
ifconfig stf0 inet6 2002:5243:e682:c000::1 prefixlen 16

and the interface will activate a piece of code which controls the
internal address of your host. you won't have to touch your routing
table, you won't have to declare a new alias and you won't have to
activate ipnat.
--
int main(int c,char**v){int b,e=(c>>24)+6,g=c==1?1:e>>4;
char*d=c==1?"d3JpdGUgaW4gQw==":g==2?*v:v[c-1];b=c<<6|(*d
+(*d>96?-71:*d>58?-65:*d>47?4:*d>46?16:19));if(*d==61?0:
*d){if((e&=15)>7)putchar((b>>(e-=8))&255); d++;main(((e|
32)<<24)|(b&4095),&d);}return g<2&&c>2?main(--c,v):1;}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Pavel Cahyna]

Post by Rodolphe De Saint Leger

Post by Pavel Cahyna
Can you please describe in more detail what it is supposed to do and how
the network setup looks like? What are the problems you are trying to
solve?
Pavel

Actually, the stf interface does not check for misc cases which should
not come under nomal conditions. I've added some tests to ensure that
packets which try to abuse the 6to4 encapsulation gets dropped before
getting into the network. I tried to apply the security draft on 6to4.
my isp gives me a box which handles the ipv4 nat. This box don't know
about 6to4 encapsulation but you can configure a 'dmz host'. This host
will receive any incoming packet wich does not belong to an existing
nat session. let's say that my internal network is 192.168.7.0/24 and
the nat box has the internal address 192.168.7.1, the external address
82.67.230.130, and my 'dmz' netbsd has the address 192.168.7.2.
Actually you can make stf working by using a bimap rule, an alias on
lo0 and a trick in the routing table.
ifconfig stf0 create
ifconfig stf0 inet6 2002:5243:e682::1 prefixlen 16
ifconfig lo0 82.67.230.130 alias
/sbin/route delete 82.67.230.130
/sbin/route add 82.67.230.130 192.168.7.2
bimap vlan1 82.67.230.130/32 -> 192.168.7.2/32 ipv6

I am using that successfully for a long time, and I don't even need to
change the routing table. Why is it needed for you?

Pavel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rodolphe De Saint Leger]

Post by Pavel Cahyna
I am using that successfully for a long time, and I don't even need to
change the routing table. Why is it needed for you?

Sorry, I did a mistake in my route...

this is
/sbin/route add 82.67.230.130 192.168.7.1

If you don't do this your 6to4 host can't reach a service redirected
on your nat point (a web server for example)
--
int main(int c,char**v){int b,e=(c>>24)+6,g=c==1?1:e>>4;
char*d=c==1?"d3JpdGUgaW4gQw==":g==2?*v:v[c-1];b=c<<6|(*d
+(*d>96?-71:*d>58?-65:*d>47?4:*d>46?16:19));if(*d==61?0:
*d){if((e&=15)>7)putchar((b>>(e-=8))&255); d++;main(((e|
32)<<24)|(b&4095),&d);}return g<2&&c>2?main(--c,v):1;}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Rodolphe De Saint Leger
Hi,
I've worked on a path for the stf interface to add more security and
nat traversal fonctionnality.
the new security features should have no visible impact, to activate
nat traversal, configure your future 6to4 router as the dmz of your
ipv4 network, and put the bit 49 of your prefix to 1.
ifconfig stf0 inet6 2002:5243:e682:c000::1 prefixlen 16

Rodolphe,

I looked at your patch this weekend, and I think that we should add
it to NetBSD except for the NAT traversal parts. The NAT traversal is
easily replicated using a packet filter. Also, it seems that the NAT
traversal feature is a candidate for re-use, even where 6to4 is not used;
for users' convenience, we could extract the NAT traversal feature into
a pseudo-interface for re-use, as somebody else suggested some time ago.

Dave

[Rodolphe De Saint Leger]

Post by David Young
I looked at your patch this weekend, and I think that we should add
it to NetBSD except for the NAT traversal parts. The NAT traversal is
easily replicated using a packet filter. Also, it seems that the NAT
traversal feature is a candidate for re-use, even where 6to4 is not used;
for users' convenience, we could extract the NAT traversal feature into
a pseudo-interface for re-use, as somebody else suggested some time ago.

NAT traversal is only in stf_getsrcifa4() (and a little CHECK_NAT define).
You may want me to provide a patch without it ?

I'll look for a pseudo nat interface solution :)

Regards,
Rodolphe
--
int main(int c,char**v){int b,e=(c>>24)+6,g=c==1?1:e>>4;
char*d=c==1?"d3JpdGUgaW4gQw==":g==2?*v:v[c-1];b=c<<6|(*d
+(*d>96?-71:*d>58?-65:*d>47?4:*d>46?16:19));if(*d==61?0:
*d){if((e&=15)>7)putchar((b>>(e-=8))&255); d++;main(((e|
32)<<24)|(b&4095),&d);}return g<2&&c>2?main(--c,v):1;}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Ignatios Souvatzis]

Post by Rodolphe De Saint Leger
Hi,
I've worked on a path for the stf interface to add more security and
nat traversal fonctionnality.

Now does NAT traversal provide more security? But anyway, for the
record: a tunneling method for (single) machines behind NAT is
Teredo. An implementation available to NetBSD would be net/miredo
in pkgsrc.

Post by Rodolphe De Saint Leger
the new security features should have no visible impact, to activate
nat traversal, configure your future 6to4 router as the dmz of your
ipv4 network, and put the bit 49 of your prefix to 1.

Hm, magic bits? Why not use an interface flag?

Post by Rodolphe De Saint Leger
ifconfig stf0 inet6 2002:5243:e682:c000::1 prefixlen 16
it will activate this 6to4 prefix with nat traversal. To emit a
packet, stf will search for the route to 82.67.230.130 and it will
take the outgoing local address as the ipv4 6to4 source.

So you still need to know the external v4 address before configuration?

Regars
-is

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Rodolphe De Saint Leger]

Post by Ignatios Souvatzis
Now does NAT traversal provide more security? But anyway, for the
record: a tunneling method for (single) machines behind NAT is
Teredo. An implementation available to NetBSD would be net/miredo
in pkgsrc.

The security part is not about nat. At the beginning I only search for
the nat traversal.
The other checks came after to deny some attacks.

I knew about miredo, but I do not have a single machine :)

Post by Ignatios Souvatzis
Hm, magic bits? Why not use an interface flag?

All link interface flags were already used, and I didn't want to break
existing 6to4 behavior.
I searched for other solutions, but it was... worse :(

Post by Ignatios Souvatzis
So you still need to know the external v4 address before configuration?

Yes, otherwise it won't work.
--
int main(int c,char**v){int b,e=(c>>24)+6,g=c==1?1:e>>4;
char*d=c==1?"d3JpdGUgaW4gQw==":g==2?*v:v[c-1];b=c<<6|(*d
+(*d>96?-71:*d>58?-65:*d>47?4:*d>46?16:19));if(*d==61?0:
*d){if((e&=15)>7)putchar((b>>(e-=8))&255); d++;main(((e|
32)<<24)|(b&4095),&d);}return g<2&&c>2?main(--c,v):1;}

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de