Subject: REQMTS 4: definition of remote access

From: Scott Kelly <[email-masked]>
Date: Mon, 30 Oct 2000 18:03:16 -0800

This is the fourth in a series of posts aimed at resolving some issues
prior to publication of a revision of the requirements draft.

I think, based upon recent discussion on this list, that we need to more
clearly define what we mean by remote access. While a definition might
seem obvious at first glance (I sure thought it was), it turns out not
to be quite so straightforward. Skip suggested that any host which is
not physically connected to the network and must use some other method
of obtaining access to the network qualifies as a remote access host. My
difficulty with this definition is that it includes almost every
topology in which we might use ipsec, other than intranet. I think the
implied scope is far larger than what some of us would expect for this
working group.

An alternative is to try to construct an operational definition based on
what we've defined as remote access in the past. Not too long ago,
remote access meant dialing into a modem at the corporate site. Not long
after that, it came to include dialing into an ISP and tunneling the
connection across the internet using pptp, l2tp or something like that.
Now, we're attempting to extend the definition a bit by including ipsec
in the cadre of tunneling mechanisms.

I think it may be that one common thread in all the scenarios described
is that the remote system is given an address from the local network.
That is, although the system is remote in space, once access is granted,
it appears to be on the same physical lan as the other hosts.

If we use this as a filter, remote access would include access using any
arbitrary connection technology, so long as the connection was tunneled,
and the user was assigned a local lan address somehow. This squares well
with the scenarios we've defined so far, but it excludes the 2 scenarios
I was thinking about deleting, i.e.

 o extranet users using their corporate desktop systems to 
   access the remote company network of a business partner
 
 o extranet users using a business partner's system (on that
   partner's network) to access their home corporate network

unless the connections are tunnelled, and a home lan address is assigned
from the accessed network.

Does anyone have a better idea of how to define remote access (for our
purposes)?

Scott

---

From: Jan Vilhuber <[email-masked]>
Date: Mon, 30 Oct 2000 20:28:38 -0800 (PST)

Two thoughts:

a) the only difference I can think of quickly between what you define as
'remote access' and 'extranet' is the fact that one gets an ip-address, and
the other gets an ip-address and a subnet. Is that right? If so, then
the whole problem can be ignored as long as you have a generic mechanism
defined that can pass subnet information to the client (if needed), and can
influence routing at the gateway to include the subnet of the client (whether
it was pushed to the client or preconfigured).

As an example, I used to dial into the corporate network via ISDN, and I had
a subnet at home. The AAA entry for my therefore included the subnet
information, that was installed at the NAS (Network Access Server), so
routing could to the 'right thing'.

When I wasn't dialing in via ISDN, I might not get the subnet information (or
I might) depending on whether I use the same AAA-username, or any other
determination that the NAS could do (I don't remember how it was done back
then, but I can imagine multiple scenarios).

In any case, I think the difference between 'remote access' and 'extranet' is
only one or two authorization parameters (in AAA-speak). In other words:
They're pretty much the same thing.

I suppose one further comment here is that you're 'filter' below doesn't
work, since I claim to have been doing 'exrtranet' type stuff over simple
dial-up or ISDN a few years ago. It's nothing new, and nothing different.

b) why not ask the AAA WG for their definition of 'remote access'? I would
quite frankly say that we need to complement or extend any general IETF
definition of 'remote access' to ipsec, no matter how broad the IETF
definition of 'remote access' is. In other words 'for our purposes' MUST be
the same as the IETF purpose in general. We can't dumb it down, so to speak.
I'm kind of going on the assumption that the AAA WG (or maybe the PPP WG?) is
the 'authority' on what remote-access is, not us. So we should bow to
whatever definition they have, and work with it.

jan

 --
Jan Vilhuber                                            [email-masked]
Cisco Systems, San Jose                                     (408) 527-0847

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 31 Oct 2000 09:18:01 +0300

> it appears to be on the same physical lan as the other hosts.

I don't think this is always the case. LAN might have public 
addresses, so that remote system would have no need to get ad address 
from the local network. We used to have such type of remote access 
for years.

Regards,
Valery.

---

From: Ben McCann <[email-masked]>
Date: Tue, 31 Oct 2000 08:14:25 -0500

> from the local network. We used to have such type of remote access 

I agree with Scott. IP address assignment is a necessary precondition for
remote access because we are designing protocols that provide the illusion
of being connected securely and directly to your home network. (At least,
that's my goal).

IP address assignment is also necessary for several practical reasons:

- IMHO, the protocol should not change behavior because the home network
  (to which the remote access client connects) has or does not have publicly
  routable addresses. We should assume the worst case (i.e. unroutable
  addresses) and design for that. 

- If you don't assign addresses then the remote access client's IP address,
  as seen by the other hosts on his home network, can be any address on the
  Internet. This implies the security gateway must also be the default route
  to the Internet for all of the hosts on the home network. This is impractical.

  The security gateway could also advertise (via the routing protocol of
  your choice) host routes for every connected client but that seems even
  worse, especially for large VPN's with 1000's of remote access clients.

- Some of our customers, for better or worse, implement internal firewall
  policy based on the addresses of hosts within the intranet. The remote
  access client must be assigned an address that identifies that client
  to the various firewalls within the intranet.

- Finally, I believe this WG needs to set constraints on the scope of the
  'remote access' problem so we can define practical and efficient
  solutions. Scott's IP address assignment is one such constraint that
  lets the WG narrow the problem space to a managable size.

-Ben McCann

-- 
Ben McCann                              Indus River Networks
                                        31 Nagog Park
                                        Acton, MA, 01720
email: [email-masked]           web: www.indusriver.com 
phone: (978) 266-8140                   fax: (978) 266-8111