Subject: RE: REQMTS 4: definition of remote access

From: "Waters, Stephen" <[email-masked]>
Date: Thu, 2 Nov 2000 12:07:31 -0000

Using the source IP address of an IPSEC tunnel to define remote/none-remote
seems prolematic to me.

My ISP gives me a fixed IP address for my dial/ISDN account, and my VPN
gateways uses Main-mode pre-shared secret (which requires prior knowledge of
the source IP address).  Other folk using xDSL may well do the same
(although we could argue that teleworkers are not 'remote').

Since the main 'problem' is mobile-working, I would like to see the working
group focus on that.  For me, this means a single system
(PC/laptop/workstation) which forms a tunnel to a security gateway connected
to the home network.  What address are used/NATed/DHCPed etc. is part of the
problem, but it should be open to the implementation on what options are
used. We have to provide a mechanism to signal an IP address ('Intranet
address') to the remote user, but this is not mandatory to make remote
access work.

Cheers, Steve.

-----Original Message-----
From: Moshe Litvin [mailto:[email-masked]]
Sent: Thursday, November 02, 2000 11:01 AM
To: 'Scott Kelly'; 'ipsra list'
Subject: RE: REQMTS 4: definition of remote access

Scott,

I strongly disagree with the definition of remote access = local address
assignment.

If you have a software installed on a laptop, that is able to establish an
IPsec tunnel with the corporate gateway but the client keeps his ISP
assigned address. Isn't this also remote access?

On the other hand if you have a GW to GW tunnel, where one of the GW decide
to NAT the incoming traffic to locally assigned address (in order the help
with routing issues). Would you call this remote access?

When looking for what is common in many remote access scenarios I see:

- "Remote module" is coming from an unexpected IP address (as opposed to GW
which have a fixed address).

- The "remote module" usually have a human operator on-line, and the
authentication process identify the human (with or without separate
authentication for the machine), and the access policy can/will also depend
on the human.

Moshe

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott Kelly
> Sent: Tuesday, October 31, 2000 4:03 AM
> To: ipsra list
> Subject: REQMTS 4: definition of remote access
>
>
> 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: "Scott G. Kelly" <[email-masked]>
Date: Thu, 02 Nov 2000 08:33:06 -0800

I've come to agree that address assignment is a common feature of many
remote access scenarios, but not all. Hence, it is not a defining
characteristic. Reviewing the charter, I note that it seems to list the
defining characteristic of remote access as being that the remote user
has a non-fixed IP address. I think this sufficiently defines remote
access for our purposes. What do you all think?

Scott

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 3 Nov 2000 09:08:17 +0300

> access for our purposes. What do you all think?

I agree.

> Scott

Regards,
Valery.

---

From: Ben McCann <[email-masked]>
Date: Fri, 03 Nov 2000 13:06:00 -0500

> access for our purposes. What do you all think?

I think this is too broadly scoped. There are multiple issues
that each need to be addressed by the WG but only a subset of
those issues may pertain to a specific remote user. For example:

- Authentication. Does the user have a cert or does he need a
  temporary cert because he is authenticating using a legacy
  mechanism such as Secure ID? A 'remote access authentication
  server' can issue a temporary cert independent of the user's
  access to the home network via zero or more security gateways.

- Routing. How does the 'home' network send packets to the user? Does
  the remote user need an IP address assigned to him by a security
  gateway? Or, does he just use his current physical address on the
  internet?

  In the latter case, as I argued in my previous posting, routing
  the remote user's traffic via a security gateway is impractical.
  If the user doesn't have an assigned IP address then perhaps
  the security gateway is superflous and instead the client should
  use IPSEC transport mode end-to-end.

Can we get more focused requirements by defining what the user needs
when he is doing remote access in each of a small set of scenarios?
Then the WG can define mechanisms to independently meet each of those
remote access user requirements. 

-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