Re: ProxyARP and IPSec
From: Alexey Kuznetsov [EMAIL PROTECTED] Date: Tue, 5 Sep 2006 13:05:30 +0400 Look into old rfc2401, search for word fragment. Then search for the same word in new rfc4301. All those 100K of new text deal with various design bugs in IPsec, mostly with pathologies encountered in the case of security gateways. (Some section there are real fun: f.e. look at section 7.2) I even was not aware of this problem. :-) Essentially, if you use ports as part of your selector, then it is impossible to handle anything other than the first fragment of a fragmented frame because the subsequent fragments will not have the ports which you need in order to match. The suggestions in 7.2 involving a seperate SA for the non-first fragments seem totally unrealistic, if you ask me. They even say the idea cannot work with ipv6, what is the point? :-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
David Miller writes: Essentially, if you use ports as part of your selector, then it is impossible to handle anything other than the first fragment of a fragmented frame because the subsequent fragments will not have the ports which you need in order to match. If you have port/protocol based selectors and you are firewalling then re-assembly is already being done so IPsec will see the re-assembled packet at little cost. Alternately in a pure IPsec configuration it possible to arrange things so that re-assembly is only done if port/protocol based selectors are used. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
* H. Peter Anvin [EMAIL PROTECTED] 2006-09-07 15:28 Thomas Graf wrote: What about adding blackhole device to be used for such routes. I believe it would be good architecture to always use devices to state directions packets are being received from and sent to. The dummy device can be used for that. I was thinking a bit beyond that, a device similiar to ifb but without a hard header to allow classification. Packets get enqueued before skb-dst gets overwritten with dst-child and dequeue handles the second half of xfrm4_output_finish2(). - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Thomas Graf wrote: What about adding blackhole device to be used for such routes. I believe it would be good architecture to always use devices to state directions packets are being received from and sent to. The dummy device can be used for that. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Alexey Kuznetsov writes: Probably, you are not aware that standard IPsec tunnel device, if it is created: 1. Probably, will not accept fragmented frames, because IPsec cannot handle them IPsec can handle them, though not particularly smoothly if the IPsec tunnel is only supposed to carry a particular portprotocol combination. 2. Probably, will have undefined MTU (65536), because of 1 An MTU that is more likely to make most things work (at least over Ethernet) is ETH_DATA_LEN - MAX_SA_LEN where MAX_SA_LEN is however much is required for IPsec (something like IP + UDP if NAT-T + ESP header + IV + padding + ESP trailer). The simplest thing is to just statically configure it. However, some implementations dynamically calculate the IPsec device MTU based on the maximum size required by any of the IPsec SAs that will go over the interface, using either a pessimistic (255) or optimistic (2) padding estimate. This can cause problems for OPSF adjacency if each side arrives at a different MTU but that can be handled by either manually configuring the device MTU or explicitly configuring the MTU that OSPF will advertise (I think Quagga supports that). Actually, this is the reason why it is not implemented. It is dirty business. :-) And the person, who implements this, has to be really... unscrupulous. :-) Exactly the same issue occurs if one implements IPsec (or any other encryption method) in user-level using a tun/tap device. Consequently while I agree that fragmentation causes an additional level of problems if one wants to have port/protocol based selectors in IPsec, I believe that most (but not all) VPN users are quite satisfied with policies containing all traffic, all ports and so will not encounter any IPsec specific problems. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Hello! sarcasm What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with Linux is too stupid to handle standard tunnel-mode IPsec I might actually get away with it. sarcasm mode is not accepted. Linux does exactly standard tunnel-mode IPsec. It does not give you device to make you totally happy. Probably, you are not aware that standard IPsec tunnel device, if it is created: 1. Probably, will not accept fragmented frames, because IPsec cannot handle them 2. Probably, will have undefined MTU (65536), because of 1 3. Probably, will screw up TCP because of 2 etc. Actually, this is the reason why it is not implemented. It is dirty business. :-) And the person, who implements this, has to be really... unscrupulous. :-) Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Alexey Kuznetsov wrote: sarcasm mode is not accepted. Linux does exactly standard tunnel-mode IPsec. It does not give you device to make you totally happy. The sarcasm was a commentary to the just switch protocols then comment. Probably, you are not aware that standard IPsec tunnel device, if it is created: 1. Probably, will not accept fragmented frames, because IPsec cannot handle them Now that's interesting. If this is true, and I have every reason to believe you know what you're talking about, then that would seem to be a problem which is hard to overcome for any security gateway, regardless of how it's implemented in the kernel -- the data originator might be on a totally different host! Furthermore, it seems to directly contradict the following statement from RFC 4303 section 3.3.4: In tunnel mode, ESP is applied to an IP packet, which may be a fragment of an IP datagram. That reading seems to imply that it should handle fragments just fine. Similarly, RFC 4301 section 13 (differences from RFC 2401) states: For tunnel mode SAs, an SG, BITS, or BITW implementation is now allowed to fragment packets before applying IPsec. This applies only to IPv4. For IPv6 packets, only the originator is allowed to fragment them. (consistently with the overall IPv6 architecture.) Transport mode is different, of course. 2. Probably, will have undefined MTU (65536), because of 1 3. Probably, will screw up TCP because of 2 etc. Actually, this is the reason why it is not implemented. It is dirty business. :-) And the person, who implements this, has to be really... unscrupulous. :-) I'm clearly failing to understand where, exactly, the problems lie. I would appreciate any pointers and/or clue transfusion... -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Stephen J. Bevan wrote: Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't If you use ipip the over-wire protocol is identical, see RFC 3884 section 3.1 or you can test it right now using manual keying (remote side uses tunnel mode, your side uses transport + ipip). To use IKE pluto would need to be hacked a bit, though most of the changes could be handled via a updown script. Interesting. It might be interesting to implement userspace (e.g. OpenSwan) in such a way that all tunnel-mode IPsec is implemented this way automatically, using an ipip interface in the kernel. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Stephen J. Bevan wrote: H. Peter Anvin writes: Fair enough. However, that does beg a question: is there any sane way to create the pseudo-device model on top of the current model, as a convenience layer? That way you could get the best of both. I assume you were using tunnel-mode IPsec and depending on exactly what you want to do you may be able to replace it with transport mode IPsec (or stay with tunnel if the extra 20 bytes of IP is not a problem) to handle host-host IPsec and use gre or ipip for overlay network. That way you get a virtual device (gre or ipip) you can route to, run OSPF on, ... etc. sarcasm What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with Linux is too stupid to handle standard tunnel-mode IPsec I might actually get away with it. /sarcasm Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't know what is. I suspect this contributes to the growth in OpenVPN as well. -hpa -- VGER BF report: U 0.53 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
sarcasm What I great idea. Now I just have to get every host I want to interoperate with to support a nonstandard configuration. The scary part is that if I motivate it with Linux is too stupid to handle standard tunnel-mode IPsec I might actually get away with it. /sarcasm Linux handles tunnel-mode IPsec in the same way that most IPsec vendors did and many still do. For example, Cisco IOS has pages and pages of documentation about how to combine IPsec with GRE in order to support securely running OSPF between sites, precisely because its IPsec didn't offer a virtual interface. However, Cisco (along with Netscreen/Juniper and Fortinet) now additionally support IPsec that uses a virtual interface and so you have a choice of using an interface or not as you see fit. I would be useful if Linux offered the option but code talks and I'm not offering a patch so I'm not in a position to complain about what Linux currently supports. Really... if saying our configuration is so screwed up that we have to run a different over-wire protocol isn't an admission of failure I don't If you use ipip the over-wire protocol is identical, see RFC 3884 section 3.1 or you can test it right now using manual keying (remote side uses tunnel mode, your side uses transport + ipip). To use IKE pluto would need to be hacked a bit, though most of the changes could be handled via a updown script. know what is. I suspect this contributes to the growth in OpenVPN as well. Haven't you heard, SSL based VPNs are the future :-) -- VGER BF report: U 0.947229 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Alexey Kuznetsov wrote: Hello! I'm thinking that David definitely has a point about having a usability problem, though. All other kind of tunnels have endpoint devices associated with them, and that would make all these kinds of problems go away, Yes, when you deal with sane practical setups, this approach is the only reasonable one. Unfortunately, IPsec is not something totally sane and practical :-), security gateway case is small part of it and routing viewpoint clashes fatally with another requirements. Pure result is that we use approach where it is possible to do everything with some efforts, rather than approach which is simple and intuitive, but does not allow to do many things. Fair enough. However, that does beg a question: is there any sane way to create the pseudo-device model on top of the current model, as a convenience layer? That way you could get the best of both. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
* David Miller [EMAIL PROTECTED] 2006-08-23 15:14 From: Thomas Graf [EMAIL PROTECTED] Date: Wed, 23 Aug 2006 21:14:25 +0200 * H. Peter Anvin [EMAIL PROTECTED] 2006-08-22 17:31 Specifically, Linux will not ProxyARP for an address unless it has a route for it, *and* that route either has a DNAT marking or points to a different interface than the input interface: I can think of a very ugly way: Use netfilter to match on the arp packet prerouting, set nfmark to some value, create a routing rule matching the fwmark again, have it look up a separate table with a dummy route pointing to a dummy device. Make sure to have a proxy neighbour entry as using the device proxy_arp sysctl would fail again. This shows we have a usability problem if that's the only way to do this :-) What about adding blackhole device to be used for such routes. I believe it would be good architecture to always use devices to state directions packets are being received from and sent to. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Hello! I'm thinking that David definitely has a point about having a usability problem, though. All other kind of tunnels have endpoint devices associated with them, and that would make all these kinds of problems go away, Yes, when you deal with sane practical setups, this approach is the only reasonable one. Unfortunately, IPsec is not something totally sane and practical :-), security gateway case is small part of it and routing viewpoint clashes fatally with another requirements. Pure result is that we use approach where it is possible to do everything with some efforts, rather than approach which is simple and intuitive, but does not allow to do many things. It is possible to simulate simple life, creating ipsecX devices with disabled xfrm and route all the tunnels there. That would be handy. I would just advice to rename one of dummy devices to ipsec0 and route all the IPsec tunnels there. It is also simple. What's about iptables, I am sorry, it is too flexible to control IPsec. :-) One day, someone with enough of energy and stamina will make flow cache to unify all the kinds of policy rules. Until that day, you have to tune all three policy sets (routing, ipsec and iptables) separately and take care of the cases, when one set has to cheat another. :-) Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
* H. Peter Anvin [EMAIL PROTECTED] 2006-08-22 17:31 Specifically, Linux will not ProxyARP for an address unless it has a route for it, *and* that route either has a DNAT marking or points to a different interface than the input interface: I can think of a very ugly way: Use netfilter to match on the arp packet prerouting, set nfmark to some value, create a routing rule matching the fwmark again, have it look up a separate table with a dummy route pointing to a dummy device. Make sure to have a proxy neighbour entry as using the device proxy_arp sysctl would fail again. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
From: Thomas Graf [EMAIL PROTECTED] Date: Wed, 23 Aug 2006 21:14:25 +0200 * H. Peter Anvin [EMAIL PROTECTED] 2006-08-22 17:31 Specifically, Linux will not ProxyARP for an address unless it has a route for it, *and* that route either has a DNAT marking or points to a different interface than the input interface: I can think of a very ugly way: Use netfilter to match on the arp packet prerouting, set nfmark to some value, create a routing rule matching the fwmark again, have it look up a separate table with a dummy route pointing to a dummy device. Make sure to have a proxy neighbour entry as using the device proxy_arp sysctl would fail again. This shows we have a usability problem if that's the only way to do this :-) What he's trying to accomplish doesn't sound all that weird, does anyone have any other ideas? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Hello! What he's trying to accomplish doesn't sound all that weird, Absolutely sane. does anyone have any other ideas? The question is where is this host really? If it is far far away and connected only via IPsec tunnel with destionation of tunnel different of host address ip ro add THEHOST dev dummy0 should be enough. It asserts that THEHOST is not on eth0. IPsec policy will figure out correct route, unless something is broken. If tunnel endpoint is THEHOST, then it is necessary to make a prescription how to reach it bypassing IPsec. This can be made with a rule telling that THEHOST is reachable from router and only from router: ip ru add from OUR_TUNNEL_ENDPOINT to THEHOST table XXX ip ro add THEHOST via THAT_ROUTE_WHICH_IS_SUPPOSED_TO_KNOW table XXX Alexey - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Alexey Kuznetsov wrote: The question is where is this host really? If it is far far away and connected only via IPsec tunnel with destionation of tunnel different of host address ip ro add THEHOST dev dummy0 should be enough. It asserts that THEHOST is not on eth0. IPsec policy will figure out correct route, unless something is broken. Just tried it, and it works as advertised. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
H. Peter Anvin wrote: Alexey Kuznetsov wrote: The question is where is this host really? If it is far far away and connected only via IPsec tunnel with destionation of tunnel different of host address ip ro add THEHOST dev dummy0 should be enough. It asserts that THEHOST is not on eth0. IPsec policy will figure out correct route, unless something is broken. Just tried it, and it works as advertised. ... except that OpenSwan will rip out the route and install a route pointing to eth0, thus breaking the thing again. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
On Wed, 2006-08-23 at 18:14 -0700, H. Peter Anvin wrote: H. Peter Anvin wrote: Alexey Kuznetsov wrote: The question is where is this host really? If it is far far away and connected only via IPsec tunnel with destionation of tunnel different of host address ip ro add THEHOST dev dummy0 should be enough. It asserts that THEHOST is not on eth0. IPsec policy will figure out correct route, unless something is broken. Just tried it, and it works as advertised. ... except that OpenSwan will rip out the route and install a route pointing to eth0, thus breaking the thing again. Use a custom updown script with Openswan to fix that. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ProxyARP and IPSec
Andy Gay wrote: Just tried it, and it works as advertised. ... except that OpenSwan will rip out the route and install a route pointing to eth0, thus breaking the thing again. Use a custom updown script with Openswan to fix that. *Nod.* I'm thinking that David definitely has a point about having a usability problem, though. All other kind of tunnels have endpoint devices associated with them, and that would make all these kinds of problems go away, plus would be nicer to deal with in iptables, dealing with routed IPsec connections, etc. -hpa - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ProxyARP and IPSec
Hello all,
I am having a puzzlement combining ProxyARP and IPsec. Specificially, I
want to take a single address from a local LAN and extend it via IPsec
to another site.
Unfortunately IPsec tunnels, unlike all other tunnels, don't have
pseudo-devices associated with them. I understand this to be from
desire of uniformity with the other modes of IPsec, but this is one of
many cases where it causes problems.
Specifically, Linux will not ProxyARP for an address unless it has a
route for it, *and* that route either has a DNAT marking or points to a
different interface than the input interface:
net/ipv4/arp.c:
855 } else if (IN_DEV_FORWARD(in_dev)) {
856 if ((rt-rt_flagsRTCF_DNAT) ||
857 (addr_type == RTN_UNICAST
rt-u.dst.dev != dev
858 (arp_fwd_proxy(in_dev, rt) ||
pneigh_lookup(arp_tbl, tip, dev, 0 {
However, since IPsec tunnels don't have interfaces associated with it,
the route to the other side of the IPsec tunnel with point to the same
interface (there is, elsewhere, a security policy associated with the
address), and this selection will fail.
Does anyone know of a trick around this issue?
-hpa
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
