Re: How does IKEv2 provide solution to remote access?

[Uri Blumenthal <uri@bell-labs.com>]

Derrell Piper wrote:
> I agree completely.  To be useful IKEv2 needs to address remote access.
> Remote access is essentially the driving factor behind IPSec gateway
> sales........

Yes! - and more:


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

On paswords - or more likely, something like SecureID or SecureNetKey
cards...

More importantly - these features ARE available now! Except that they
are implemented in a proprietary non-interoperable way.


> Make no mistake: they want this, they (think they) need this, and they
> won't deploy this technology without it.

Absolutely. Especially since the EXISTING DEPLOYED stuff supports 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?

I'd say the main draft SHOULD contain the opening for remote access.
The details, if not ready by February, can be furnished later, not
to hold the main draft up.

If at all possible and feasible given the limited time - I'd much
prefer to see #3 but by February time-frame.