Subject: RE: IPsec FAQ feedbacks
To: Jun-ichiro itojun Hagino <itojun@iijlab.net>
From: Dave Burgess <burgess@neonramp.com>
List: tech-security
Date: 01/26/2001 15:34:57
------Original Message-----
> From: itojun@itojun.org [mailto:itojun@itojun.org] On Behalf Of
> Jun-ichiro itojun Hagino
> Sent: Friday, January 26, 2001 4:09 AM
> To: Dave Burgess
> Cc: darcy@druid.net; www@NetBSD. org
> Subject: IPsec FAQ feedbacks
>
>
> >> If you have any further questions or comments I suggest bringing them
> >> up on the current-users mailing list.
> >I'm not convinced this is appropriate to the current-users forum for two
> >reasons.  The first is that these aren't really -current
> problems; they are
> >problems with using IPsec and the web page support for them.
> The second is
> >that you folks are the experts and, frankly (having been a reader of
> >current-users for years) most of the opinions we would see would
> fall into
> >the "I haven't got a clue, but let me waste your time with conjecture"
> >category that I usually post there.
>
> 	how about tech-net or tech-security?  I'd really want to share
> 	answers I make to you, with other people, so if you permit me
> 	I'd like to forward your original email (the one quoted above)
> 	and the reply I made (and am making) to tech-net.  I would like to
> 	help many people at once, than to help few guys.

I heartily agree.  I was thinking tech-security might be an appropriate
place to discuss this; at your suggestion, I have subscribed to
tech-security and have included it in CC: list.

In the preparation of the response, it occurs to me that the problem may not
be related to the IPsec code at all.  Since the problem seems to be
interaction between IPsec and NAT, it's reasonable to look at the NAT to see
why it's being so aggressive in it's desire to touch everything.

Also, please remember that I don't really KNOW what I'm talking about.  A
Master's degree coming in May and 25 years of experience really don't mean
much.  I think that most of this stuff is fairly obvious, but some of it is
pure speculation or opinion on my part.

>
> >Itojun, thank you for your patches.  Since I am using NetBSD-1.5 (the
> >release version), the patches did not apply cleanly.  I usually
> try to avoid
> >using -current on my company's firewall, but I will be bringing one of my
> >local machines up to -current in the next couple of days to try
> the changes.
> >I can use an experimental kernel to test the patches, with the
> hope that I
> >can pull them up and use them against 1.5-release.  Are there any known
> >user-land problems between 1.5 and -current that I need to know about?
>
> 	basically, you should be able to boot NetBSD-current kernel and use
> 	NetBSD 1.5 userland with it.  there are couple of changes that may
> 	bite you, like:
> 	- kmem grovellers like vmstat, netstat and some other items may not
> 	  work well.
> 	- some ioctl changes like ifconfig(8), mount_mfs and others.
> 	- NetBSD-current integrates UBC (unified buffer cache), which has
> 	  significant change in memory management.

The usual stuff, then.  The 'ifconfig' program is the only one I'd be really
worried about at this point.

>
> 	I'm not sure if my recent IPsec change will make it to NetBSD 1.5.1.
> 	there are certain amount of change in network packet memory (mbuf)
> 	management, and I need to be highly careful about this.

The version numbers have changed from the source module patches you sent me
to the ones in NetBSD-current.  Some of the changes are in there, most of
the ones in netinet6 are not.  Of course, you know that since you appear to
be the author.

>
> >The changes to the web page don't really help.  By adding
> reasons why IPsec
> >interoperability won't work, all it's done is made it clear that
> people that
> >need to use this protocol in a production environment should
> look elsewhere.
> (snip)
> >With the recent
> >explosion of cable modems for home users and DSL implementations
> for offices
> >and businesses (remember, I own an ISP company) as well as Corporations
> >fielding IPsec gateways into their networks, it is clear that
> IPsec *MUST*
> >work with NATed networks if it is to be usable in a large context.
>
> 	I can't agree more, it would be necessary for IPsec tunnel gateways
> 	to work with NAT, or packet filters.  However, protocol-wise and
> 	implementation-wise, they really implement conflicting components.
> 	- NAT tries to look at packet content and rewrite it.  IPsec encrypts
> 	  it and secures it.

If a packet does not meet the modification criteria for NAT, then why would
the packet ever be modified?  That is the crux of the conceptual problem I'm
having here.  Please note that this is not (at first blush) an IPsec
problem, Itojun-san.

> 	- Packet filter tries to drop, or pass, the packets based on certain
> 	  rules.  IPsec policy lookup engine does almost the same, and
> 	  decides if Packet needs to be handled in the security engine.

I don't have a problem with dropping too many packets.  If that was the
problem I'm having, I could relax one or more rules to allow the rules to be
processed correctly.  Of course, if I'm not using a rule in the IPsec engine
for dropping a packet, then the policy engine's actions should be limited to
validate or decrypt a packet.  If a packet is invalid, it gets dropped; not
because of a general firewall rule, but because of a security violation.

> 	- Almost every packet filter implementations do not play nicely
> 	  with tunneled packets.  some of packet filter implementation do it
> 	  nicely, since either they are implemented as L2 entity, or
> 	  since they restrict themselves to look at packets at certain location.
> 	  There are many people with many different goals here, here's very
> 	  hard design decision to make.
>
> 	We are going through integration process, at this very moment.
> 	We are trying, but we have very limited human resources and time.
> 	Your bug reports and feedbacks are really important.  I would really
> 	like to thank you.  I understand your pain, we are doing our best.
>

I appreciate your efforts, and I am an avid supporter of NetBSD and KAME.  I
pounded on the Microsoft folks at Networld+Interop on the KAME and NetBSD
systems' behalf.  It didn't help (as far as I can tell) but it was
interesting to hear them hem and haw.

> 	Btw, if you really need it to work quickly for your day job, how about
> 	hire some consultants like wasabi and sponsor the task (or convince
> 	your boss to do so)?  That would make "limited human resource and
> 	time" part of the issue a little bit better.  My personal interest
> 	reside in IPsec and IPv6, and NOT in NAT.  I'm actually trying very
> 	hard to eliminate NAT, and so that to be honest to what I tell people,
> 	I almost never use NAT.  So for me it is rather hard to test NAT-IPsec
> 	interaction, since I have very little motivation on NAT.

Two reasons:

1)  He would rather spend the money on a PIX.
2)  He doesn't have nearly the interest in NetBSD that I do.

While the transition to IPv6 is a good goal, most of the Internet just isn't
ready yet.  Until then, NAT is the closest thing we have to a workable
solution.

>
> >Also, I'm not married to the gif interface.  In my particular case, it's
OK
> >because I have two NetBSD-1.5 machines, but I understand that there are
> >places where the gif interface isn't supported.  I could as easily use
the
> >gre interface, or the ipip interface, or whatever it's going to take to
make
> >this work better.
>
> 	I don't really recommend the use of gif, ipip or gre to circumvent
> 	issues with IPsec.  Because they do not implement RFC2401 conformant
> 	"IPsec tunnel", they will cause interoperability problem if you use
> 	other implementation on the other side.

Right.  For purposes of discussion, let's assume that the gre interface is
as close as we have to a portable generic interface.  I, on the other hand,
will be using nothing but NetBSD machines.

I know I don't have nearly the background or experience, but it strikes me
as a relatively simple design.  Whether this is the way this is done now or
not (and remember, I'm new to this discussion) the theory should be
applicable.

	1)  IPsec tunnel mode interfaces are consulted first.  The packet is
encapsulated and reinsinuated into the IP stream with the new
source/destination packets.  At this point, the source interface address
should be set as the external port address and the source address should be
set 'as if' NAT had been performed.  I'm trying to think if there's any
reason why the IPsec tunnel mode interfaces shouldn't go directly to step 3
or 4 below.
	2)  NAT is performed.  This changes the header (the source IP address).
Note that tunnel interfaces shouldn't be considered in NAT processing unless
a tunnel interface is specifically included in the NAT rules.  Actually, it
should be the other way around.  When the NAT rules are parsed, they should
be applied to the appropriate interface queues and applied to those packets
as they traverse the queue.
	3)  IPsec transport mode interfaces and policy engine are consulted.  The
packet is encrypted, but the headers are left alone.
	4)  Tunnel interfaces are then consulted.   If a packet meets the tunnel
criteria, it is queued into the tunnel interface queue.
	5)  The firewall code is consulted.  If a packet is supposed to be blocked,
it is.

I have been following the discussions in the KAME mailing list long enough
to know that this division of IPsec (between steps 1 and 3) is problematic.

>
> >- Does IPsec tunnel mode really redirect the packets?  If so, what
interface
> >is it using?  Where is the non-routable address being munged by NAT in
this
> >case?
>
> 	what is meant by "redirect" here?

Here is my supposition:

If I am sending a packet from 192.168.0.10 to 192.168.1.10 through
204.248.21.50, the packet leaves my desktop (192.168.0.10) going to
192.168.1.10.  *It gets to default gateway with the IPsec engine, where it
is encapsulated in a packet that now has a source address of the gateway
(204.248.21.50) and the destination address of the other gateway
(204.248.21.62).*  Neither of these addresses is translated (by NAT), so the
packet is tunneled/routed to the destination gateway (204.248.21.62).  It
gets to the remote gateway, where it isn't processed by NAT (there is no
matching outgoing rule and no incoming redirect).  It is grabbed by the
IPsec engine (since there is an SAD and an SPD for this address pair) and is
de-encapsulated and pushed into the appropriate interface queue.

The sentence with the *s around it is what I mean by redirect.

Since the IPsec encapsulated non-routable address never appears on the IPNAT
designated interface, I can't see how it can be incompatible.  The NAT code
shouldn't be touching packets that do not meet the NAT translation criteria.

>
> >- Would adding a special SAD and SPD for the non-routable addresses help?
> >Right now, the only hosts that have security profiles are the two servers
> >(204.248.21.50 and 204.248.21.62).  Would a SAD or SPD for the
> non-routables
> >help either way?
>
> 	give me more concrete example using setkey(8) syntax, otherwise
> 	i cannot understand what you are proposing to do.

This is the setkey configuration I was thinking about when I asked the
question.  This file would sit on a NetBSD workstation inside my network:

#
#  Workstation to local gateway
#
add 192.168.0.1 192.168.0.10 esp 11174
	-m transport
	-E blowfish-cbc "internalinternal";
add 192.168.0.10 192.168.0.1 esp 11175
	-m transport
	-E blowfish-cbc "internalinternal";
#
#  Local Gateway to remote gateway
#
add 192.168.1.1 192.168.0.1 esp 11176
	-m tunnel
	-E blowfish-cbc "passwordpassword";
add 192.168.0.1 192.168.1.1 esp 11177
	-m tunnel
	-E blowfish-cbc "passwordpasswd02";
#
#  Workstation to remote gateway
#
add 192.168.0.10 192.168.1.1 esp 11178
	-m tunnel
	-E blowfish-cbc "internalexternal";
add 192.168.1.1 192.168.0.10 esp 11179
	-m tunnel
	-E blowfish-cbc "externalinternal";
#
#  SPDs for above
#
spdadd 192.168.0.1/32[any] 192.168.0.10/32[any] any
	-P in ipsec
	esp/transport/192.168.0.1-192.168.0.10/require;
spdadd 192.168.0.10/32[any] 192.168.0.1/32[any] any
	-P out ipsec
	esp/transport/192.168.0.10-192.168.0.1/require;
spdadd 192.168.1.1/32[any] 192.168.0.1/32[any] any
	-P in ipsec
	esp/tunnel/204.248.21.62-204.248.21.50/require;
spdadd 192.168.0.1/32[any] 192.168.1.1/32[any] any
	-P out ipsec
	esp/tunnel/204.248.21.50-204.248.21.62/require;
spdadd 192.168.1.0/24[any] 192.168.0.10/32[any] any
	-P in ipsec
	esp/tunnel/204.248.21.62-192.168.0.1/require;
spdadd 192.168.0.10/32[any] 192.168.1.0/24[any] any
	-P out ipsec
	esp/tunnel/192.168.0.1-204.248.21.62/require;

From a routing perspective, I can see some serious problems with this
mechanism, but it was just a passing thought.  Specifically, if the IPsec
processing really does encapsulate the packets and designate them for
routing, then this new mechanism might be just what the doctor ordered.

>
> >- IPsec transport mode can be set up easily between two hosts.  If tunnel
> >mode is unusable in a real IPv4 Internet environment, that should be made
> >more clear.
>
> 	specwise, tunnel mode has no dependency to private address cloud
> 	(10/8, 192.168/16, whatever).  so the above "if" is false.
> 	where did you get the impression?
>

You are right, I over-simplified the condition, sort of.

Take my situation (as well as the situations of anyone on DSL, or a cable
modem, or with private network addresses) as the basis for the statement.

You can't use private addresses in a real IPv4 Internet environment.  You
have to have something that translates those addresses.  With the exception
of setting up a router, then a NAT, then IPsec (at least two separate boxes,
maybe three, twice (one set for each end)) there isn't a relatively simple
way to have two private networks talk to one another securely and still have
access to the Internet with our current IPv4 tools.

I can't believe that I'm the only person using NetBSD that is having this
problem.

> >- If it's possible to work around these problems using link-local IPv6
> >addresses over a gif tunnel instead of straight IPv4 addresses, I'd be
> >willing to try that.
>
> 	i don't understand "these problems".  what is it?
> 	if you want no IPv6 traffic to get exchanged over gif tunnel,
> 	see the very end of gif(4).
>

These problems:  IPsec walking on the NAT address translations, or vice
versa.  Since "IPv4 addresses with NAT with IPsec with a firewall" seems to
be a non-starter, perhaps there's another mechanism using IPv6 addresses
that might work.

This is the basic dilemma for me:

If I set up the network so that I can use IPsec between my two networks,
then my firewalls would be incapable of sending traffic to any place except
those two networks.  NAT is no longer an option, so my private addresses
must remain private.  As soon as I add NAT, IPsec stops working since the
packet headers somehow get modified during the transition.  I can then not
talk between my two networks.  I'm still unclear on whether or not the
firewall is part of the problem, but I have an experiment set up to help me
understand that interaction more clearly.

> >- Is it possible to use the gif interface, without IPsec, to set up an
> >unsecured VPN through a routed environment?  If so, that would solve the
> >short term problem and give me some time before the IPsec stuff
> catches up.
>
> 	yes of course that is possible.

I will start there, then.

Here is the course of action for my next few steps:

1)  I will set up a gif <-> gif network between the two gateways.  If I can
pass traffic on that, I will be in the place I need to be in the short term.

2)  I will start looking at the IPsec code to see what is causing the
specific problems I am having.  Once I find the errors, I'll let you know.