Re: How does IKEv2 provide solution to remote access?

[Derrell Piper <ddp@electric-loft.org>]

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...
>