[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How does IKEv2 provide solution to remote access?
I agree completely. To be useful IKEv2 needs to address remote access.
Remote access is essentially the driving factor behind IPSec gateway
sales. IKEv2 needs to account for:
1) NAT traversal
2) Internal addressing -- including IP/DHCP, DNS, and WINS
configuration through a tunnel
3) Legacy authentication for SecurID, Passwords, OTP, and
Challenge/Response Tokens (CRACK)
Without these features, people simply will not deploy IKEv2 to replace
IKEv1 because they won't be able to do what they want to do -- surf
their corporate intranets (which are often not globally routable and
often NAT'd themselves) and read their mail while also being behind a
NAT. It's way beyond hideous, but people want this for all sorts of
confused reasons and they're not budging.
I don't know about the rest of you, but I want to be able to use that
cable modem sitting on the desks of the Marriott's and the W's of the
world to log in back home securely using IPSec. And so do all of the
business travelers of the world. Now this is a NAT traversal example,
but the other two items are equally important. Network administrators
simply will not reconfigure their entire network to introduce IPSec
into it. They want to assign internal 10-net addresses to clients so
legacy IP-based access control schemes continue to work as well as (or
as poorly as) they have ever worked. They want their clients to use
Radius passwords and/or SecurID cards to log in and for once they also
want this part to be secure! You can even go so far as to ship a
product with a built-in CA and they'll still insist on using passwords,
trust me.
Make no mistake: they want this, they (think they) need this, and they
won't deploy this technology without it.
It seems we have three obvious paths: 1) ignore the problem; 2) release
an initial IKEv2 draft to meet Jeff's February deadline followed by a
quick revision with remote access additions; 3) wait until we've got it
all and release just one draft. Given my belief that this needs to be
included, and given Jeff's challenge, the question I think we ought to
be resolving now is: so what's the viability and risk/reward of doing
#2 vs. #3?
Derrell
On Tuesday, December 3, 2002, at 09:15 AM, Uri Blumenthal wrote:
> Yes, it better. Unless we want to see proprietary extensions
> all over again - all incompatible with each other...
>