IPSEC N-1 NAT issues
Ian Lawley
two don't work very well without some extra workarounds.
One common solution that just involves changing the IPSEC client code, is to
wrap all the IPSEC traffic with an UDP IP frame. This involves yet another
level of encapsulation and can present security issue. UDP is not stateful
and will need hole opening in the firewall.
Is there an RFC for this method ? I couldn't see one. Are there any more
favoured workarounds.
Thanks,
-ian
-ian
nex...@my-deja.com
We have a solution for IPSec passing through NAT. We allow up to 100
simultaneous Contivity sessions to pass-through our box. Take a look
at www.nexland.com .
Thanks,
Greg
In article <8h6jrn$cn4$2...@wnsgs006.europe.nortel.com>,
Sent via Deja.com http://www.deja.com/
Before you buy.
js...@dontspamme.havoc.gtf.gatech.edu
-> Ian,
-> We have a solution for IPSec passing through NAT. We allow up to 100
-> simultaneous Contivity sessions to pass-through our box. Take a look
-> at www.nexland.com .
Can you give any details on how Nexland does this? I tried looking
on your website but all I could find was "ISB allows IPsec to pass-through".
I would assume there would have to be more details on the patent application,
which is or will be a public document - please save me the trouble of looking
it up. Please don't point me at the link "Learn How IPSec works with
ISB2LAN" because frankly that didn't tell me much. Also, does the
ISB2LAN do stateful packet inspection? I see it does appear to allow a DMZ
host. Do you intend to implement logging (preferably via syslog) in
the near future?
Without more details it is hard to recommend your box to clients as
a security solution. Right now I would be far more inclined to recommend
an IPsec gateway solution from SonicWall or Allied Telesyn, or perhaps
a stripped down Unix (BSD or Linux) box. However, your box does have
an attractive price and form factor, and is probably easier to configure
and maintain than a Unix IPsec gateway, so if I could be convinced it
is secure, I would probably at least recommend it as one of many options.
On the other hand, the gateway solution does eliminate the need to buy,
install and maintain IPsec capability on the client PCs.
Finally, timhiggins.com claims the latest firmware for the Ugate 3000
supports IPsec passthrough, and Linksys is alleged to be beta-testing
an IPsec passthrough capability. Does Nexland license the technology
to them, or did they develop it independently? The Ugates in particular
seems to be quite similar to the ISB2LANs in many respects.
--
John Cronin
Ian Lawley
"only NAT box with multisession IPSec 'pass thro' technology" is *complete
rubbish*. Obviously put together by a marketing person with no awareness of
what implementations other vendors are shipping.
At Nortel Networks we have been shipping products that do this for more than
18 months ! The BayStack Internet Internet does BOTH multisession IPSEC and
PPTP pasthrough with N-1 NAT.
http://www.nortelnetworks.com/products/02/datasheets/2985.pdf
And you don't need to patent how vendors are doing this, because it NOT
magic.
All you need to do is look for something unique in both the IKE key
management protocol and in the ESP enscapsulation and encryption ptotocol
(that comprise an IPSEC session), which you can use instead of the Source
Port to keep track of each IPSEC session that traverses the N-1 NAT gateway.
These unique identifiers are available in both the IKE and ESP protocol of
IPSEC. Note that IPSEC AH is not N-1 NATable.
IPsec AH protocol is explicitly intended to detect what NAT is good at. That
is altering the header of the packet. So when NAT alters the address
information in the header of the packet, the destination host receives the
altered packet and begins digesting the AH message. The AH routines at this
host will invalidate the packet since the contents of the headers have been
altered. As a result, AH will not work through NAT device (1-1 or N-1).
IKE protocol N-1 NAT methodology
In IKE you need to keep track of the ISAKMP SA which is identified by the
Initiator's cookie and the Responder's cookie, contained in the ISAKMP
header.
The N-1 NAT device should use these cookie fields to identify the internal
IP address mapping to the external IP address
ISAKMP Header Format
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Initiator !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Responder !
! Cookie !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Message ID !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ESP protocol N-1 NAT methodology
ESP using Tunnel Mode encrypts the entire private datagram.
The ESP protocol has no ports associated with it, and TCP/UDP port are
encrypted in the ESP payload. The N-1 NAT device has to use another
mechanism than TCP/UDP ports to uniquely identify the destination of inbound
traffic.
The N-1 NAT Device has to be aware of the security association established
between the 2 IPSec systems so that it could map the outbound SA to the
inbound SA for a specific IP address.
Each SA has an SPI, Security Parameter Index, associated with it. The SPI is
an arbitrary number defined by the first 32 bits of the ESP header. In
combination with the destination IP address (outer header) and security
protocol, it uniquely identifies the Security Association for this datagram.
The SPI value is selected by the destination system at the SA establishment.
If the N-1 NAT can implement some way to keep track of the SPI's and
determine a valid amount of time to keep them active then a NAT device can
handle IPsec traffic.
ESP header Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data* (variable) |
~ ~
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 bytes) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Regards,
-ian
<js...@dontspamme.havoc.gtf.gatech.edu> wrote in message
news:8idecu$mfk$1...@news-int.gatech.edu...
js...@dontspamme.havoc.gtf.gatech.edu
looking for. The Instant Internet boxes look nice, I will have to find
some pricing information - buycomp.com does not seem to have these.
Ian Lawley <ila...@nortelnetworks.com> wrote:
-> Frankly my oppinion is that Nexland claim that their ISB2LAN product is the
-> "only NAT box with multisession IPSec 'pass thro' technology" is *complete
-> rubbish*. Obviously put together by a marketing person with no awareness of
-> what implementations other vendors are shipping.
-> At Nortel Networks we have been shipping products that do this for more than
-> 18 months ! The BayStack Internet Internet does BOTH multisession IPSEC and
-> PPTP pasthrough with N-1 NAT.
-> http://www.nortelnetworks.com/products/02/datasheets/2985.pdf
-> And you don't need to patent how vendors are doing this, because it NOT
-> magic.
I assume then that if Nexland tries to patent the method you described,
that Nortel (and other vendors) will most likely contest the patent? A
lot of these software patents are quite silly. I remember when AT&T
patented the backing store technique that had been in use (in Xwindows,
for example) for many years - a sure sign that the patent office has no
clue when it comes to software.
--
John Cronin
Ben McCann
> determine a valid amount of time to keep them active then a NAT device can
> handle IPsec traffic.
Your IPSEC/NAT presentation was very thorough but you didn't explain just how
hard the 'If the N-1 NAT can implement...' problem is. The SPI's are encrypted
when they are negotiated by IKE thus a NAT box can't deterministically know
which station behind the NAT has reserved which SPI's. Instead, it has to
_guess_ the association of inbound and outbound SPI's that were created by
a typical bidirectional data flow. (The SPI's in the two directions are almost
certainly different).
There is a Linux IPSEC NAT that implements the following heuristic:
1. Watch for new SPI values flowing from stations behind the NAT towards
the Internet.
2. Start a timer when a new outbound (towards the internet) SPI is detected.
3. Wait for return IPSEC packet coming back from the internet that also has
a new SPI. It must return before the timer expires.
4. The new inbound SPI must be associated with the sender of the last new
outbound SPI thus you know which station behind the NAT gets data with
that new inbound SPI.
This obviously has some problems but it does work most of the time:
1. Data flows must be bi-directional.
2. The gateway/ipsec-peer on the internet must reply within a reasonable time.
3. Two stations behind the NAT can't start new IPSEC security associations at
the same time.
4. Two stations behind the NAT can't pick the _same_ SPI value for their incoming
traffic. The SPI is a random 32-bit value so the odds are low...
Another, proprietary, alternative is to tunnel IPSEC in another NAT-able protocol
such as UDP or TCP. Several vendors, including Indus River, implement this choice
because it also addresses traversal of firewalls along the path between the
two IPSEC peers. Its ugly, but it works _all_ the time.
-Ben McCann
--
---
Ben McCann Indus River Networks
31 Nagog Park
Acton, MA, 01720
email: bmc...@indusriver.com web: www.indusriver.com
phone: (978) 266-8140 fax: (978) 266-8111
js...@dontspamme.havoc.gtf.gatech.edu
-> Another, proprietary, alternative is to tunnel IPSEC in another NAT-able protocol
-> such as UDP or TCP. Several vendors, including Indus River, implement this choice
-> because it also addresses traversal of firewalls along the path between the
-> two IPSEC peers. Its ugly, but it works _all_ the time.
Does Indus River use UDP or TCP? I think I would prefer TCP, personally,
as it allows my stateful packet inspection router/firewall do it's thing
better.
--
John Cronin
Ben McCann
firewall think that the data is simple secured web traffic.
-Ben McCann
--
nexl...@my-deja.com
our multi-session IPsec (and PPTP, BTW) "Pass-Through". The patent is valid
and not a gimmic. Neither Nortel nor anyone else produced anything
resembling our method getting IPsec packets to the right computer/port on the
LAN with up to 100 VPN sessions running at once (using any ESP mode IPsec VPN
client). Our box is $299 retail and I assure you, it is being used by many
Fortune 100 companies who LOOKED for a practical a viable solution but
weren't able to find one until they evaluated the ISB2LAN (our xDSL/Cable
version router).
Our website (www.nexland.com) does contain marketing blurbs and simple
explanations, but they aren't false.
In article <8il0qk$2ns$1...@news-int.gatech.edu>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Ben McCann
http://www.cc.gatech.edu/linux/LDP/HOWTO/VPN-Masquerade-HOWTO.html#toc1
Is your solution _different_ from the approach used by Linux? If it is _not_
then I assume your patent won't be approved because there was existing prior art.
If your solution _is_ different then I'm curious if it works with IPSEC ESP
security associations constructed using IKE (ISAKMP)?
-Ben McCann