Subject: REQMTS 3: scenarios

From: Scott Kelly <[email-masked]>
Date: Fri, 27 Oct 2000 09:55:01 -0700

Hi All,

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

I am considering deleting 2 or the scenarios from the draft:

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

The rationale for deleting these is the same in both cases: this is
standard ipsec, and not specific to remote access.

Any opinions on this?

Thanks,

Scott

---

From: Skip Booth <[email-masked]>
Date: Fri, 27 Oct 2000 13:23:02 -0400 (EDT)

> standard ipsec, and not specific to remote access.

To me, remote access is defined as any situation where you are not physically
connected to the network and must use some other means of obtaining access to
that network.  In this case, that method is IPsec.  So I am not sure why these
two scenarios are not considered remote-access.  In addition, it's not clear to
me why these situations don't have exactly the same requirements as the other
remote-access scenarios.  You still need to be able to obtain an IP address and
potentially authenticate with some user information such as a password or
one-time token.  In addition, these scenarios will also have additional
requirements such as NAT and Firewall interactions.  IMO, these scenarios should
remain.  I believe the IPsec WG will be the home of the IPsec NAT/FW issues so
maybe just a reference to the problem is sufficient in the IPSRA requirements
doc.

-Skip

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Fri, 27 Oct 2000 14:15:49 -0400

Has anyone here been following aaarch?

It seems to me (from what little I was able to discern from my seat in the
hallway at the first RG meeting), that these were some of the scenarios they
were trying to address.

I wonder whether they are treating these scenerios as remote access.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott Kelly
> Sent: Friday, October 27, 2000 12:55 PM
> To: ipsra list
> Subject: REQMTS 3: scenarios
>
>
> Hi All,
>

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 27 Oct 2000 13:39:32 -0700

>   partner's network) to access their home corporate network

To someone configuring the security gateway on the responder end of 
these scenarios, the setup is indistinguishable from the road warrior 
dialing in through the ISP du jour. That is, the fact that a 
business-to-business extranet has been set up in irrelevant, since 
the rules for that particular user will be unrelated to the rules for 
the rest of the business partner.

Personally, I wouldn't mind throwing out all extranet scenarios 
because they have not been shown to be nearly as relevant as WAN and 
road warrior.

>standard ipsec, and not specific to remote access.

Well, it is "remote access", but it is no different than road warrior 
remote access.

--Paul Hoffman, Director
--VPN Consortium

---

From: Scott Kelly <[email-masked]>
Date: Fri, 27 Oct 2000 14:37:30 -0700

Hi Paul,

Comments below...

Paul Hoffman / VPNC wrote:
<trimmed...> 

> Well, it is "remote access", but it is no different than road warrior

I don't think this is completely accurate: road warrior remote access
entails someone dialing an isp, and then connecting to the local net -
the system they use may or may not be "known". The first scenario above
entails a connection from a "known" system within your local net to a
remote net. The second scenario above entails a connection from an
"unknown" system within an "unknown" network connecting into your local
net. The vulnerabilities are different in each case. 

Scott

---

From: Scott Kelly <[email-masked]>
Date: Fri, 27 Oct 2000 14:31:08 -0700

Hi Skip,

Skip Booth wrote:

<trimmed...> 

> two scenarios are not considered remote-access.

I think I see what you mean. I also think this means we need to clarify
what we mean by remote access. One starting definition might made be in
terms of the access properties: we have typically used "remote access"
in our ipsec discussions to refer to one remote system seeking access to
a "local" network via dialup, or dsl/cable connections. 

If we connect a remote network (as opposed to a single user) to a local
network via an ipsec connection, we typically refer to this as a vpn,
i.e. the remote network *is* directly connected to the local network by
virtue of the tunnel. This would seem to be different than what we
typically refer to as remote access, although this is exactly what
occurs if someone has a home network with a security gateway via which
they access the company net.

The distinguishing characteristic seems to be that in the remote access
case, we have one-to-many or few-to-many access from the remote net to
the local net, rather than having both nets wide open to one another.
This way of looking at it tends to support your argument that these
scenarios should remain.

<trimmed the rest...>

Scott

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 29 Oct 2000 16:19:52 -0800

>Well, it is "remote access", but it is no different than road warrior 

Not necessarily. In the Extranet case, there is typically an implied
need for access control. That is, Extranet partners should typically
not be connected to each other, nor allowed access to resources outside
of the Extranet. 

In practice, these kind of restrictions are typically enforced via
per-user filters, either of the routing, SPD, or packet filtering
variety.

---

From: "sankar ramamoorthi" <[email-masked]>
Date: Sun, 29 Oct 2000 19:43:37 -0800

I was trying to understand from the charter to figure out what 'remote
access' is defined as..

This line caught my attention.

"There are some fundamental differences, that are relevant to IPSec usage,
between these remote access scenarios and scenarios where both parties
reside in fixed locations: "

To me remote access is a scenario where both the parties do not reside in
fixed
locations (that is the policy describing ipsec proxy addresses of any one
side is not
known beforehand to the other side and needs to be found out in a dynamic
fashion).

-- sankar --

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Scott Kelly
Sent: Friday, October 27, 2000 2:31 PM
To: Skip Booth
Cc: ipsra list
Subject: Re: REQMTS 3: scenarios

Hi Skip,

Skip Booth wrote:

<trimmed...>

<trimmed the rest...>

Scott