headers
John Denker | 1 Mar 2009 11:53
Favicon

Re: [Openswan dev] Qustion about Nat-t

On Thu, 26 Feb 2009, I wrote:

>> Just as a general reminder:  Anybody who is considering using
>> NAT traversal should seriously consider *not* using NAT traversal.

>> The alternative is to use IPv6

On 02/27/2009 12:34 PM, Paul Wouters replied:

> People have no choice now.

I disagree; see below.

> I'll toast with you at the next IETF Scotch bof "To the universal
> deployment of IPv6".

That is at least two leaps removed from being factual and
relevant.

 *) First of all, "universality" has got nothing to do with
  this discussion.  If I want to make an IPsec connection
  from point A to point B over IP -- be it IPv4 or IPv6 --
  all I need is raw IP connectivity from A to B.  I don't
  need to consider all possible A in the universe, or all 
  possible B in the universe, just the particular A and B
  that I actually care about.

  We don't even have universal IPv4 connectivity ... but
  still, people manage to send IPsec over IPv4.  Universality
  is a red herring.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Paul Wouters | 1 Mar 2009 22:38
Gravatar

Re: [Openswan dev] Qustion about Nat-t

On Sun, 1 Mar 2009, John Denker wrote:

> *) NAT is a kludgey way of extending the IPv4 address space.
>  IPv6 is an incomparably better way of extending the IPv4
>  address space.

> *) A basic principle of engineering is to aim for the moving
>  target.  NAT is the way of the past.  The future will be
>  more and more IPv6.

The move to more ipv6 will only happen with more 6to4 and 4to6
NAT's, and horribly DNS kludges to make ipv4-only systems talk
to ipv6-only systems and visa versa.

Welcome to the real world, Neo.

> Really?  Do you actually know of any home gateways that will
>  a) forward IKE and ESPinUDP, but
>  b) not properly terminate SIT tunnels, and
>  c) not even forward SIT packets?
>
> If you know of any such, I'd like to hear about it.  I don't
> actually know of any.  I'd be astonished if they made up 90%
> of the market.  I'd be mildly surprised if they covered even
> 10% of the Openswan users.

How do you set this up on a Windows laptop or Windows Mobile
telephone, without installing additional software and
Administrative permissions? 90% of Openswan users have an
openswan server with incoming Windows and OSX clients.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Michael H. Warfield | 3 Mar 2009 19:52

Re: [Openswan dev] Qustion about Nat-t

Hey Paul,

On Sun, 2009-03-01 at 16:38 -0500, Paul Wouters wrote:
> On Sun, 1 Mar 2009, John Denker wrote:

> > *) NAT is a kludgey way of extending the IPv4 address space.
> >  IPv6 is an incomparably better way of extending the IPv4
> >  address space.

> > *) A basic principle of engineering is to aim for the moving
> >  target.  NAT is the way of the past.  The future will be
> >  more and more IPv6.

> The move to more ipv6 will only happen with more 6to4 and 4to6
> NAT's, and horribly DNS kludges to make ipv4-only systems talk
> to ipv6-only systems and visa versa.

	According to a recent Goggle experiment, where they "enrolled" a random
sampling of visitors to their site into an IPv6 experiment, the US now
ranks 5th in percentage of clients who will preferentially and
successfully use IPv6 if offered.  That was behind Russia, Norway,
France, and the Ukraine.  This was largely thanks to Mac's and Airport
Extreme base stations which comprised half of the US traffic that worked
and utilized IPv6.  I'm sure the client users never even recognized it
was happening.  Admittedly, the absolute percentages were very small
(.45% of US clients) but still not bad for clients who have no idea what
it is and no incentive to turn it on and it's just there out of the box
in arbitrary environments.  And that's client side.  That says nothing
of servers deployed with IPv6 enabled.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michael H. Warfield | 3 Mar 2009 21:01

Re: [Openswan dev] Qustion about Nat-t

On Sun, 2009-03-01 at 16:38 -0500, Paul Wouters wrote:
> On Sun, 1 Mar 2009, John Denker wrote:

> > *) NAT is a kludgey way of extending the IPv4 address space.
> >  IPv6 is an incomparably better way of extending the IPv4
> >  address space.

> > *) A basic principle of engineering is to aim for the moving
> >  target.  NAT is the way of the past.  The future will be
> >  more and more IPv6.

> The move to more ipv6 will only happen with more 6to4 and 4to6
> NAT's, and horribly DNS kludges to make ipv4-only systems talk
> to ipv6-only systems and visa versa.

> Welcome to the real world, Neo.

	Actually...  What I used NAT-T for more than anything else is drilling
through obsessive firewalls that do not permit ESP, AH, or SIT through.
Then I can tunnel IPv6/SIT over ESP-in-UDP (over UDP, over IP, sigh).
That can tunnel an entire v6 net over a wall that doesn't permit SIT
(protocol 41).  What I would love (and I guess is available with IKE2)
is the ability to directly tunnel v6 in ESP on V4 cutting out the SIT
layer there.  I can do that with OpenVPN (ala the now defunct Join
project out of Germany) but OpenVPN is a performance dog being in user
space and I see a lot of anomalous UDP errors with OpenVPN.  So I find
IPSec a more reliable answer to my IPv6 over obsessive IPv4 firewall
problem, even if I have to (currently) shim it with another layer.

> > Really?  Do you actually know of any home gateways that will
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Wouters | 3 Mar 2009 21:32
Gravatar

Re: [Openswan dev] Qustion about Nat-t

On Tue, 3 Mar 2009, Michael H. Warfield wrote:

> > > *) NAT is a kludgey way of extending the IPv4 address space.
> > >  IPv6 is an incomparably better way of extending the IPv4
> > >  address space.
> 
> > > *) A basic principle of engineering is to aim for the moving
> > >  target.  NAT is the way of the past.  The future will be
> > >  more and more IPv6.
> 
> > The move to more ipv6 will only happen with more 6to4 and 4to6
> > NAT's, and horribly DNS kludges to make ipv4-only systems talk
> > to ipv6-only systems and visa versa.
> 
> 	According to a recent Goggle experiment, where they "enrolled" a random
> sampling of visitors to their site into an IPv6 experiment, the US now
> ranks 5th in percentage of clients

> This was largely thanks to Mac's and Airport
> Extreme base stations which comprised half of the US traffic that worked
> and utilized IPv6.  I'm sure the client users never even recognized it
> was happening. 

Exactly, they were behind a NAT. A specific 4to6 NAT. Now what will your ipv4 IPsec
client do? Connect to an ipv6 IPsec via NAT? Probably the 4to6 is clever enough
not to attempt that job and let this client out as ipv4 NAT.

> than IPv4 /32 routable host addresses (whether they exist or not).  Oh,
> and I should note, those IPv6 networks are production space only.  I
> don't include the 2002::/16 6to4 space or the 2001::/32 Teredo space, or
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael H. Warfield | 3 Mar 2009 21:52

Re: [Openswan dev] Qustion about Nat-t

On Tue, 2009-03-03 at 15:32 -0500, Paul Wouters wrote:
> On Tue, 3 Mar 2009, Michael H. Warfield wrote:
> 
> > > > *) NAT is a kludgey way of extending the IPv4 address space.
> > > >  IPv6 is an incomparably better way of extending the IPv4
> > > >  address space.
> > 
> > > > *) A basic principle of engineering is to aim for the moving
> > > >  target.  NAT is the way of the past.  The future will be
> > > >  more and more IPv6.
> > 
> > > The move to more ipv6 will only happen with more 6to4 and 4to6
> > > NAT's, and horribly DNS kludges to make ipv4-only systems talk
> > > to ipv6-only systems and visa versa.
> > 
> > 	According to a recent Goggle experiment, where they "enrolled" a random
> > sampling of visitors to their site into an IPv6 experiment, the US now
> > ranks 5th in percentage of clients
> 
> > This was largely thanks to Mac's and Airport
> > Extreme base stations which comprised half of the US traffic that worked
> > and utilized IPv6.  I'm sure the client users never even recognized it
> > was happening. 
> 
> Exactly, they were behind a NAT. A specific 4to6 NAT. Now what will your ipv4 IPsec
> client do? Connect to an ipv6 IPsec via NAT? Probably the 4to6 is clever enough
> not to attempt that job and let this client out as ipv4 NAT.
> 
> > than IPv4 /32 routable host addresses (whether they exist or not).  Oh,
> > and I should note, those IPv6 networks are production space only.  I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael H. Warfield | 3 Mar 2009 21:59

Re: [Openswan dev] Qustion about Nat-t

On Tue, 2009-03-03 at 15:32 -0500, Paul Wouters wrote:
> On Tue, 3 Mar 2009, Michael H. Warfield wrote:
> 
> > > > *) NAT is a kludgey way of extending the IPv4 address space.
> > > >  IPv6 is an incomparably better way of extending the IPv4
> > > >  address space.
> > 
> > > > *) A basic principle of engineering is to aim for the moving
> > > >  target.  NAT is the way of the past.  The future will be
> > > >  more and more IPv6.
> > 
> > > The move to more ipv6 will only happen with more 6to4 and 4to6
> > > NAT's, and horribly DNS kludges to make ipv4-only systems talk
> > > to ipv6-only systems and visa versa.
> > 
> > 	According to a recent Goggle experiment, where they "enrolled" a random
> > sampling of visitors to their site into an IPv6 experiment, the US now
> > ranks 5th in percentage of clients
> 
> > This was largely thanks to Mac's and Airport
> > Extreme base stations which comprised half of the US traffic that worked
> > and utilized IPv6.  I'm sure the client users never even recognized it
> > was happening. 
> 
> Exactly, they were behind a NAT. A specific 4to6 NAT. Now what will your ipv4 IPsec
> client do? Connect to an ipv6 IPsec via NAT? Probably the 4to6 is clever enough
> not to attempt that job and let this client out as ipv4 NAT.
> 
> > than IPv4 /32 routable host addresses (whether they exist or not).  Oh,
> > and I should note, those IPv6 networks are production space only.  I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael H. Warfield | 3 Mar 2009 22:16

Re: [Openswan dev] Qustion about Nat-t

On Tue, 2009-03-03 at 15:32 -0500, Paul Wouters wrote:
> On Tue, 3 Mar 2009, Michael H. Warfield wrote:
> 
> > > > *) NAT is a kludgey way of extending the IPv4 address space.
> > > >  IPv6 is an incomparably better way of extending the IPv4
> > > >  address space.
> > 
> > > > *) A basic principle of engineering is to aim for the moving
> > > >  target.  NAT is the way of the past.  The future will be
> > > >  more and more IPv6.
> > 
> > > The move to more ipv6 will only happen with more 6to4 and 4to6
> > > NAT's, and horribly DNS kludges to make ipv4-only systems talk
> > > to ipv6-only systems and visa versa.
> > 
> > 	According to a recent Goggle experiment, where they "enrolled" a random
> > sampling of visitors to their site into an IPv6 experiment, the US now
> > ranks 5th in percentage of clients
> 
> > This was largely thanks to Mac's and Airport
> > Extreme base stations which comprised half of the US traffic that worked
> > and utilized IPv6.  I'm sure the client users never even recognized it
> > was happening. 
> 
> Exactly, they were behind a NAT. A specific 4to6 NAT. Now what will your ipv4 IPsec
> client do? Connect to an ipv6 IPsec via NAT? Probably the 4to6 is clever enough
> not to attempt that job and let this client out as ipv4 NAT.
> 
> > than IPv4 /32 routable host addresses (whether they exist or not).  Oh,
> > and I should note, those IPv6 networks are production space only.  I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Reeves, Phillip A. | 5 Mar 2009 16:18
Picon
Favicon

[Openswan dev] Dev Question - Reset SA Timers

I'm in the middle of a NASA research project and lab assessment of IPSec for use in space to ground communication. I could use a little advise from the experts.

 

A (perhaps) unique aspect of our space - ground communication path is that there are predictable periods of 1-way comm where only the forward link or return link is available. During these periods we must continue to communicate over whichever direction is available. One example would be to continue the return link flow of health and status data to the ground when the forward link is unavailable.

 

During an earlier phase of this study we demonstrated that manual keying provides one approach for dealing with periods of 1-way comm. Existing manual keyed SAs continue to flow and new ones can initiate provided they match a defined transform set. These SAs never expire. But there are well known limitations to manual keying that we hope to avoid.

 

IKE-based keying is a goal of the study and there is an aspect where your expertise and advise would be appreciated. We think we know that existing IKE-based SAs will continue to allow data to flow over 1-way links until the associated SA expires. Our current goal is to develop a command that will allow all SAs to reset their expiration timers before the start of a 1-way comm period. We've been looking over the Openswan source considering various ways this could be done and have not identified a good approach. I would appreciate any suggestions you may have before I charge off on non-productive paths.

 

Thank you in advance for any assistance you are able to provide.

 

Phillip

 

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev
Permalink | Reply | 0 comments |

Gmane