[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(NAT) Host NAT issues and Security Policy Servers



-----BEGIN PGP SIGNED MESSAGE-----


  [I'm going to appologize in advance for cross posting so widely.
I'm feeling a bit like every working group I attend is dealing with
the same problems. 
  I also, due to fog, missed both nat and aaa this morning. I heard
the aaa BOF didn't arrive at any clear conclusions, and I'm glad there
wasn't a fire drill during the NAT meeting or someone might have been
trampled. ]

    Mike> Jeff,

    Mike> The framework that is used by DNAT, and now host-NAT,
    Mike> consists of several fundamental ideas:

    Mike> - Tunneling between a router or device with a public IP address
    Mike> and an end host.

  DNAT specifically supported IPsec tunnelling to the NAT device. This
is important to a number of environments where they actually want
authenticated outbound firewall traversal.

    Mike> - Using TCP/UDP ports or some other mechansim  or combinations
    Mike> thereof to uniquely identify hosts from the private address
    Mike> space.
    Mike> - Assignment of global IP addresses to hosts for them to use when
    Mike> talking with the outside world.

  I want to note that this problem is essentially *IDENTICAL* to do
the IPsec road warrior configuration problem. It is also a variation
of the problem that Luis et al. designed their security policy system to
solve. (draft-ietf-ipsec-sps-00.txt coming to a draft directory near
you. I don't have the URL handy right now)
  
    Mike> The PDP was meant just to distribute port numbers.  Nothing
    Mike> else.  In our way of thinking, assignment of an IP address
    Mike> or other parameters to a host might as well occur using an
    Mike> existing extensible protocol, such as DHCP or as part of a
    Mike> tunnel establishment, rather than reproducing existing
    Mike> functionality.  These parameters may require renegotiation.
    Mike> See the "Perspectives" section of the DNAT draft for a
    Mike> discussion of this.  The PDP is not limited in any sense.

  The SPS policy server could well assign numbers.
  And yes, DHCP could do it. This was suggested for client
configuration in the road warrior case. 
  In addition, extensions to ISAKMP are being suggested to do client
configuration.

    Mike> I recently started writing a draft about the general
    Mike> framework of end-to-end communication through a NAT, listing
    Mike> the issues that any solution must address.  Here are some of
    Mike> the most relevant issues:

  I want to point out that IPsec security gateways are essentially
stateful routers. Alas, we reinvent ATM! As such, the end-to-end
issues with NAT and with IPsec are essentially the same. (ignoring the
fact that NAT and IPsec often sit on the same box)
  As far as I'm concerned, the IP address in protocol problem typified
by FTP, IRC (dcc), RealX, is less of a problem. These problems are
simple and easily solved both at the NAT stage (after protocol design)
and at the protocol design stage. But, getting rid of IP addresses in
the TCP data flow doesn't solve anything: The question that should be
asked by the IAB is does ICMP work through a NAT/IPsec box. 

  The real issue is not, can NAT work in the presence of end-to-end
IPSEC (DNAT and host-NAT are existence proofs that it is possible
to do something), nor is the issue that IPsec makes traditional NAT
hard to do, but that IPsec and NAT both introduce stateful
routing. diffserv tries to not introduce more state.

  I think, the model that we have essentially converged upon in IPsec,
NAT, diffserv, intserv, rap, aaa, qos... is of the end host going out
to the network *policy* server and saying: "I'd like to do X"
  The policy server responds and says: "I'll let you do X, but to do
so you will have to perform the following things: A, B, C."
  If I'm not mistaken (and I probably am, since the closest I ever got to
an actual telephone switch, a DMS100, was when I once fixed the test
guy's lab Xterminal many years ago), SS7 provides similar types of
conversations.  
 
  To recap, there are multiple protocols (or proposals) so far for
carrying questions from the end systems to the intermediate systems:
	1. RSVP 
	2. ISAKMP 
	3. host NAT, DNAT, DHCP
	4. router/prefix discovery stuff in v6.
	5. BBN's SPS protocol
	6. SOCKS
	7. ARP, ND

  [You may think that ARP doesn't belong, but I think that it does
because it is something that one does prior to sending a packet to the
node in question. There is no IS unless you consider a bridge to be a
layer 2 IS]

  From intermediate systems to policy servers we have:
	1. COPS
	2. SPS
	3. radius
	4. AAA
	5. did I miss something?

  A significant thing about the SPS work is that it operates both from
ES to IS, and from IS to IS, and from IS to policy server. In
addition, it permits *discovery* of IS systems and associated policy
servers in the forwarding path, which isn't something that I see in
the other protocols.
  I would like to see COPS and SPS merged somehow, and I wonder if
this can provide the common AAA protocol, as well as the common
DNAT/host-NAT, IPsec tunnel end point discovery, ... protocol. I don't
know what this does to RSVP in the diffserv border router model.

  hmm. Pizza is here.

]              At IETF43. Continental sucks                     |1 Fish/2 Fish[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |Red F./Blow F[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

  

  
  
  
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQBVAwUBNmyBlx4XQavxnHg9AQH2AgH/f5ltwjZS94Tiw3z8fJReRyBJXCiypQbX
si7pz5NxK+TnQxj5DwmeJydFAxd8hTaYhEzA7eSLyPa7zn0B34MZQg==
=IusE
-----END PGP SIGNATURE-----


Follow-Ups: