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

Re: Discovery of tunnel server from ISP POP

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


>>>>> "Stephen" == Stephen Waters <Stephen.Waters@Digital.com> writes:
    Stephen> A number of short-comings are leveled at IPSEC regarding address
    Stephen> assignment mechanisms.  The DHCP+ISAKMP draft covers the
    Stephen> allocation of an Intranet address, but how does an IPSEC client
    Stephen> discover the Internet address of the IPSEC Security Gateway?

  This is the topic for the proposed KX and TX records. If the "intranet" is
world routable (not necessarily a reasonable assumption in the IPv4 world,
but IPv6 suggests it isn't an issue), then it may also be reasonable to send
an ICMP message (an echo) to the desired end node, and watch for an ICMP
admin denied message coming back. (One could even just transmit the TCP SYN,
but that may be more information than one desires to reveal in the
clear. Another option is to send an ISAKMP initiator message)

  It would come back from security gateway. If one had sent an ISAKMP
message, that might be a signal to the gateway to initiate an ISAKMP with
the end node. Given appropriate certificates presented by the client and
gateway to establish that each is authorized to speak for their respective
entities (users on the client, networks on gateway), then the gateway
discovery is done.

  If the network is not routable, then the LAC (LAC === ?? variation of NAS?)
has to configured to know where the tunnel is supposed to go anyway. In that
case, I see it as being fairly reasonable to provide this information in an
IPCP message during PPP.

    Stephen> Is this worth a (very short) draft proposing an extension to
    Stephen> IPCP?  Since this exchange provides Internet addresses, is there
    Stephen> any need to protect/encrypt this information?  If there is, then

  I think it is worth a draft.
  I do not think it is necessary to encrypt the info. Any observer that can
see that information is going to be able to later see the encrypted
(tunnelled) packets hit that gateway address anyway. Can the data be modified
in transit across that modem link? If it is, then the client simply fails to
establish a secure tunnel. Denial of service. If the attacker can modify,
they can also just garble to cause the same affect.

   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
   Michael Richardson |Network and security consulting and contract programming
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. 





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

iQB1AwUBNODPW9iXVu0RiA21AQEg2wMAoZZXuREfPxmdAj/jxXlF4QHQ07Ka8gla
etxkh43bjq6wOrmDqF+ZuWlNExQDuLH1O1UzMHF8zKhmGEaZhNKxACJM6NCh4EVa
Nd48khfzXneRcSSdw6cVfIBfVrBQbdLQ
=NaJA
-----END PGP SIGNATURE-----
References: