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

Re: Re[8]: ISAKMP performance

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


>>>>> "pcalhoun" == pcalhoun  <pcalhoun@usr.com> writes:
    pcalhoun>         In this application, it is implied that end to
    pcalhoun> end security is used (hopefully using IPSEC). Againk, as
    pcalhoun> I have repeted many times, I am not attempting to
    pcalhoun> encrypt the users' data, merely trying to get around all

  Okay, so don't encrypt the user's data.

    pcalhoun> of the security holes in the L2TP protocol by using
    pcalhoun> IPSEC underneath it. In this case, authentication of
    pcalhoun> each L2TP peer is done using IPSEC. This will ensure
    pcalhoun> that no malicious user inserts data into a tunnel data
    pcalhoun> stream.

  Here you say that you *are* trying to protect the user's data
stream. Integrity and origin authentication is a form of protection. 
Same difference really from the ISAKMP point of view.
     
    pcalhoun>         There seems to be this misunderstanding that I
    pcalhoun> am trying to encrypt the users' data, which is obviously
    pcalhoun> wrong. There is no trust between the NAS and the
    pcalhoun> firewall! I am simply trying to get around the L2TP
    pcalhoun> deficiencies.

  So the firewall does the authentication of the user. Okay.
  Thus, the NAS and the firewall need only share a *single* SA for all
users. 

    pcalhoun> protocol runs over IP (just because of the name implies
    pcalhoun> that it makes ALL IP traffic secure, does not mention
    pcalhoun> scaling problems).

  At least three different suggestions have been made on scaling:
	1. move security to the user's end. NAS not involved (this
	isn't L2TP)
	2. cache the NAS<->firewall SAs on the authentication server,
	or some other place instead of NVRAM.
	3. do ISAKMP on another machine (or machines).

    pcalhoun>         As I mentioned earlier, I think that the IPSEC
    pcalhoun> needs to advertise the target applications which it is
    pcalhoun> trying to address in order to ensure that we do not have
    pcalhoun> too many of these WGs blindly point to IPSEC for all
    pcalhoun> underlying security and key management.

  In that IPsec is a producer of security services, and L2TP,
MobileIP, and ?? are consumers of security services, I agree: producer
and consumer must agree on what is being "sold"/"bought".
  Unfortunately, that involves both parties. That means that the
consumers must brief the producers on their requirements, and also
means that the producers must understand what the consumers are
doing. IETF meetings are ideal for this kind of thing: a similar thing
happened last year between mobileip and ipsec.

    Bill> It's not clear what doing a secure tunnel from the NAS
    Bill> to the firewall buys me as an end user, as I can't trust
    Bill> the phone network to be secure.
     
  So, forget about ISDN caller id. That's a joke.

   :!mcr!:            |  Network security programming, currently
   Michael Richardson | on contract with DataFellows F-Secure IPSec
 WWW: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.

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

iQB1AwUBM9eGhaZpLyXYhL+BAQExiQMAtyPMkqgAycMB4QYX5BqTnj9ABFXuzFwW
HcDRb2vg6c58ZGeg2pjdfjOQSGo6s2BHiX2UDlVd7cb3c6qG4AZYBYMbn2Ems2WL
Qdtzzj1X+5+7xw4mjp2mNSbssYKLeklP
=FBI2
-----END PGP SIGNATURE-----
References: