From owner-ietf-ipsra@mail.vpnc.org  Wed Nov  1 15:25:35 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17743
	for <ipsra-archive@odin.ietf.org>; Wed, 1 Nov 2000 15:25:34 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06157
	for ietf-ipsra-bks; Wed, 1 Nov 2000 11:25:44 -0800 (PST)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06153
	for <ietf-ipsra@vpnc.org>; Wed, 1 Nov 2000 11:25:43 -0800 (PST)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21)
	id <VGRCRM5Z>; Wed, 1 Nov 2000 11:31:24 -0800
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id VGRCRM5X; Wed, 1 Nov 2000 11:31:19 -0800
From: Scott Kelly <skelly@redcreek.com>
To: Jan Vilhuber <vilhuber@cisco.com>
Cc: ipsra list <ietf-ipsra@vpnc.org>
Message-ID: <3A006FE7.FD22D4C3@redcreek.com>
Date: Wed, 01 Nov 2000 11:32:55 -0800
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: REQMTS 4: definition of remote access
References: <Pine.LNX.4.21.0010302015440.3252-100000@janpc-home.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Jan,

Sorry for the delayed response. Comments interspersed...

Jan Vilhuber wrote:
> 
> 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?

Well, that's not clear at this point: it's possible to connect in an
extranet situation without having an address assignment occur. On the
other hand, based on the definition I tried to formulate, if both get
addresses assigned, the subnet is immaterial, because both meet the
suggested criteria (local address assigned).

<much trimmed...>

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

Two comments: first, my aim *is* to construct a definition which extends
the general definition, which is why I first referred to ppp et al.
Second, I think we must limit the scope of what we intend to address. I
think the definition Skip offered encompasses all of ipsec except for
intranet, and this scope is too large for this working group. That's why
I'm trying to find a more precise definition. I don't think what I've
suggested clashes with pppext, l2tpext, or aaa, but I agree that we
should ensure that such a clash does not occur.

Scott


From owner-ietf-ipsra@mail.vpnc.org  Wed Nov  1 15:35:37 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20026
	for <ipsra-archive@odin.ietf.org>; Wed, 1 Nov 2000 15:35:36 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06323
	for ietf-ipsra-bks; Wed, 1 Nov 2000 11:34:45 -0800 (PST)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06319
	for <ietf-ipsra@vpnc.org>; Wed, 1 Nov 2000 11:34:45 -0800 (PST)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21)
	id <VGRCRM6L>; Wed, 1 Nov 2000 11:40:36 -0800
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id VGRCRM6K; Wed, 1 Nov 2000 11:40:32 -0800
From: Scott Kelly <skelly@redcreek.com>
To: Valery Smyslov <svan@trustworks.com>
Cc: ipsra list <ietf-ipsra@vpnc.org>
Message-ID: <3A007210.54803747@redcreek.com>
Date: Wed, 01 Nov 2000 11:42:08 -0800
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: REQMTS 4: definition of remote access
References: <200010310618.JAA11374@relay1.trustworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi Valery,

Valery Smyslov wrote:
> 
> On 30 Oct 00, at 18:03, Scott Kelly wrote:

<much trimmed...>

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

This tends to support Skip's view that all access from a system which is
not on the same network is remote access. I see the logic in this, but
must reassert that this broadens the scope of this working group beyond
the intent of its charter. Perhaps what we need to do is qualify the
term "remote access" somehow, so that we narrow the scope to fit within
this working group's charter.

Scott


From owner-ietf-ipsra@mail.vpnc.org  Wed Nov  1 18:50:01 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05834
	for <ipsra-archive@odin.ietf.org>; Wed, 1 Nov 2000 18:50:01 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA12722
	for ietf-ipsra-bks; Wed, 1 Nov 2000 14:56:19 -0800 (PST)
Received: from mail.nexsi.com (sdsl-208-185-176-210.dsl.sjc.megapath.net [208.185.176.210])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12718
	for <ietf-ipsra@vpnc.org>; Wed, 1 Nov 2000 14:56:14 -0800 (PST)
Received: from denali (dynam69.nexsi.com [172.16.212.69])
	by mail.nexsi.com (8.9.3/8.9.3) with SMTP id PAA11552;
	Wed, 1 Nov 2000 15:06:29 -0800
From: "sankar ramamoorthi" <sankar@nexsi.com>
To: "Scott Kelly" <skelly@redcreek.com>,
        "Valery Smyslov" <svan@trustworks.com>
Cc: "ipsra list" <ietf-ipsra@vpnc.org>
Subject: RE: REQMTS 4: definition of remote access
Date: Wed, 1 Nov 2000 14:59:33 -0800
Message-ID: <LBELLCAPBPEPMOMELLJDOEEMCDAA.sankar@nexsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3A007210.54803747@redcreek.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

Hi,

I was trying to go through the charter again to figure out where it mentions
that 'virtual presence' is a MUST,
but could not find it. Isn't requiring remote acces MUST maintain 'virtual
presence' limiting? It takes away some remote access scenarios.

For remote access in the context of IPsec, how about a definition like

'remote access in the context of IPsec is when any one of the communicating
parties has to dynamically discover some
or all of SPD policy from the other party after suitable authentication,
before conducting the actual ipsec exchange.
The authenticating entity can choose to download more information in
addition to SPD policy information'.

This definition works well with PIC, virtual presence (if needed), addition
configuration information..

Welcome your comments,

Thanks,

-- sankar --

-----Original Message-----
From: owner-ietf-ipsra@mail.vpnc.org
[mailto:owner-ietf-ipsra@mail.vpnc.org]On Behalf Of Scott Kelly
Sent: Wednesday, November 01, 2000 11:42 AM
To: Valery Smyslov
Cc: ipsra list
Subject: Re: REQMTS 4: definition of remote access


Hi Valery,

Valery Smyslov wrote:
>
> On 30 Oct 00, at 18:03, Scott Kelly wrote:

<much trimmed...>

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

This tends to support Skip's view that all access from a system which is
not on the same network is remote access. I see the logic in this, but
must reassert that this broadens the scope of this working group beyond
the intent of its charter. Perhaps what we need to do is qualify the
term "remote access" somehow, so that we narrow the scope to fit within
this working group's charter.


Scott



From owner-ietf-ipsra@mail.vpnc.org  Thu Nov  2 06:48:59 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA20512
	for <ipsra-archive@odin.ietf.org>; Thu, 2 Nov 2000 06:48:58 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id CAA29132
	for ietf-ipsra-bks; Thu, 2 Nov 2000 02:55:41 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [199.203.73.68])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29124
	for <ietf-ipsra@vpnc.org>; Thu, 2 Nov 2000 02:55:38 -0800 (PST)
Received: from gray (localhost [127.0.0.1])
	by michael.checkpoint.com (8.9.3/8.9.1) with SMTP id NAA25329;
	Thu, 2 Nov 2000 13:01:15 +0200 (IST)
From: "Moshe Litvin" <moshe@checkpoint.com>
To: "'Scott Kelly'" <skelly@redcreek.com>,
        "'ipsra list'" <ietf-ipsra@vpnc.org>
Subject: RE: REQMTS 4: definition of remote access
Date: Thu, 2 Nov 2000 13:01:12 +0200
Message-ID: <002801c044bc$37680c00$0b8d96d4@checkpoint.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <39FE2864.218F4367@redcreek.com>
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

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: owner-ietf-ipsra@mail.vpnc.org
> [mailto:owner-ietf-ipsra@mail.vpnc.org]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 owner-ietf-ipsra@mail.vpnc.org  Thu Nov  2 08:08:02 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09288
	for <ipsra-archive@odin.ietf.org>; Thu, 2 Nov 2000 08:08:01 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id EAA05269
	for ietf-ipsra-bks; Thu, 2 Nov 2000 04:01:53 -0800 (PST)
Received: from ctron-dnm.ctron.com (firewall-user@ctron-dnm.cabletron.com [12.25.1.120])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05261
	for <ietf-ipsra@vpnc.org>; Thu, 2 Nov 2000 04:01:52 -0800 (PST)
Received: (from uucp@localhost)
	by ctron-dnm.ctron.com (8.8.7/8.8.7) id HAA21011;
	Thu, 2 Nov 2000 07:13:20 -0500 (EST)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1)
	id xma020999; Thu, 2 Nov 00 07:12:45 -0500
Received: from new-ims-av.ctron.com (new-ims-av.ctron.com [134.141.200.50])
	by roc-mail2.ctron.com (8.8.7/8.8.7) with SMTP id HAA09642;
	Thu, 2 Nov 2000 07:07:32 -0500 (EST)
Received: from 134.141.200.123 by new-ims-av.ctron.com (InterScan E-Mail VirusWall NT); Thu, 02 Nov 2000 12:11:23 -0000 (GMT Standard Time)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0)
	id <VZ1TLJSR>; Thu, 2 Nov 2000 12:07:32 -0000
Message-ID: <29752A74B6C5D211A4920090273CA3DC01D285B6@new-exc1.ctron.com>
From: "Waters, Stephen" <Stephen.Waters@riverstonenet.com>
To: "'Moshe Litvin'" <moshe@checkpoint.com>
Cc: "'ietf-ipsra@vpnc.org'" <ietf-ipsra@vpnc.org>
Subject: RE: REQMTS 4: definition of remote access
Date: Thu, 2 Nov 2000 12:07:31 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>


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:moshe@checkpoint.com]
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: owner-ietf-ipsra@mail.vpnc.org
> [mailto:owner-ietf-ipsra@mail.vpnc.org]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 owner-ietf-ipsra@mail.vpnc.org  Thu Nov  2 12:28:35 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26017
	for <ipsra-archive@odin.ietf.org>; Thu, 2 Nov 2000 12:28:35 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24770
	for ietf-ipsra-bks; Thu, 2 Nov 2000 08:25:42 -0800 (PST)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24762
	for <ietf-ipsra@vpnc.org>; Thu, 2 Nov 2000 08:25:41 -0800 (PST)
Received: by mail.redcreek.com with Internet Mail Service (5.5.2650.21)
	id <VGRCR336>; Thu, 2 Nov 2000 08:31:36 -0800
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id VGRCR335; Thu, 2 Nov 2000 08:31:33 -0800
From: "Scott G. Kelly" <skelly@redcreek.com>
To: "Waters, Stephen" <Stephen.Waters@riverstonenet.com>
Cc: "'Moshe Litvin'" <moshe@checkpoint.com>,
        "'ietf-ipsra@vpnc.org'"
	 <ietf-ipsra@vpnc.org>,
        "Smyslov, Valery" <svan@trustworks.com>,
        "Ramamoorthi, Sankar" <sankar@nexsi.com>
Message-ID: <3A019742.10B7A18A@redcreek.com>
Date: Thu, 02 Nov 2000 08:33:06 -0800
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Re: REQMTS 4: definition of remote access
References: <29752A74B6C5D211A4920090273CA3DC01D285B6@new-exc1.ctron.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

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 owner-ietf-ipsra@mail.vpnc.org  Fri Nov  3 01:54:49 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09247
	for <ipsra-archive@odin.ietf.org>; Fri, 3 Nov 2000 01:54:48 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id WAA02398
	for ietf-ipsra-bks; Thu, 2 Nov 2000 22:02:28 -0800 (PST)
Received: from relay1.trustworks.com (zuka.trustworks.com [212.114.5.147])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA02385
	for <ietf-ipsra@vpnc.org>; Thu, 2 Nov 2000 22:02:25 -0800 (PST)
Received: by relay1.trustworks.com (8.8.5/1.11)
	id JAA03449; Fri, 3 Nov 2000 09:09:12 +0300 (MSK)
Message-Id: <200011030609.JAA03449@relay1.trustworks.com>
Received: from svan-pc(212.114.5.100) by zuka via smap (V2.0)
	id xma003429; Fri, 3 Nov 00 09:08:42 +0300
From: "Valery Smyslov" <svan@trustworks.com>
Organization: TWS
To: "Waters, Stephen" <Stephen.Waters@riverstonenet.com>,
        "Scott G. Kelly" <skelly@redcreek.com>
Date: Fri, 3 Nov 2000 09:08:17 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: REQMTS 4: definition of remote access
CC: "'Moshe Litvin'" <moshe@checkpoint.com>,
        "'ietf-ipsra@vpnc.org'" <ietf-ipsra@vpnc.org>,
        "Ramamoorthi, Sankar" <sankar@nexsi.com>
In-reply-to: <3A019742.10B7A18A@redcreek.com>
X-mailer: Pegasus Mail for Win32 (v3.12b)
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7BIT

On 2 Nov 00, at 8:33, Scott G. Kelly wrote:

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

I agree.

> Scott

Regards,
Valery.



From owner-ietf-ipsra@mail.vpnc.org  Fri Nov  3 13:43:39 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05240
	for <ipsra-archive@odin.ietf.org>; Fri, 3 Nov 2000 13:43:38 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09874
	for ietf-ipsra-bks; Fri, 3 Nov 2000 10:00:27 -0800 (PST)
Received: from post.indusriver.com (indus-bh.indusriver.com [63.81.64.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09869
	for <ietf-ipsra@vpnc.org>; Fri, 3 Nov 2000 10:00:24 -0800 (PST)
Received: from indusriver.com (172.16.4.254) by post.indusriver.com (Worldmail 1.3.167); 3 Nov 2000 13:05:15 -0500
Message-ID: <3A02FE88.94BA9BD4@indusriver.com>
Date: Fri, 03 Nov 2000 13:06:00 -0500
From: Ben McCann <bmccann@indusriver.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scott G. Kelly" <skelly@redcreek.com>
CC: "'ietf-ipsra@vpnc.org'" <ietf-ipsra@vpnc.org>
Subject: Re: REQMTS 4: definition of remote access
References: <29752A74B6C5D211A4920090273CA3DC01D285B6@new-exc1.ctron.com> <3A019742.10B7A18A@redcreek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

"Scott G. Kelly" wrote:
> 
> 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?

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: bmccann@indusriver.com           web: www.indusriver.com 
phone: (978) 266-8140                   fax: (978) 266-8111


From owner-ietf-ipsra@mail.vpnc.org  Fri Nov  3 13:43:53 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05335
	for <ipsra-archive@odin.ietf.org>; Fri, 3 Nov 2000 13:43:52 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA09228
	for ietf-ipsra-bks; Fri, 3 Nov 2000 09:47:20 -0800 (PST)
Received: from mailhost.pmprofilemetals.ch ([194.29.0.140])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09222
	for <ietf-ipsra@vpnc.org>; Fri, 3 Nov 2000 09:47:16 -0800 (PST)
Date: Fri, 3 Nov 2000 09:47:16 -0800 (PST)
From: hv@of-hachetal.de
Message-Id: <200011031747.JAA09222@ns.secondary.com>
Received: from h809 ([63.30.197.239]) by mailserver.pmprofilemetals.ch
          (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100)
          with SMTP id ACB167; Fri, 3 Nov 2000 15:46:27 +0100
To: hv@of-hachetal.de
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>


Herbal V: An Incredible All-Natural Healthy Alternative 


  Herbal V is the All Natural Approach to Male Virility,
  Vitality and Pleasure.



Available N o w ! 


Welcome to the New Sexual Revolution.

It's the all natural male potency and pleasure pill that men 
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.

Amazing word of mouth praise on Herbal V has been spreading 
like wildfire-already over 1,500,000 men  have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!


Herbal V... Bringing Back the Magic!


1,585,000 men can't be wrong. To date over 1 million men 
have tried the super supplement Herbal V.
Here is why: 

No Doctor Visit Required 
Available Over the Counter 
Not a Drug 
100% Natural 
Safe, No Worries 
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals 
Guaranteed Potency & Purity 

Be a Real Man Again!

Questions and Answers

What is Herbal V?

Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it 
was available to the general public. 

How does Herbal V work?

Developed by a team whose goal was to create the perfect 
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience. 

What can Herbal V do for me?

Herbal V helps support male sexual function and 
pleasure in a safe and natural manner. Simply put, 
it can make your sex life incredible. 

Is Herbal V Safe?

One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety. 

Herbal V: Safe - Natural - Exciting

Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any 
elements or traces of any prescription drug. Herbal V 
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic! 

Herbal V: Ingredients

Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris. 
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels. 
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in 
desire. Avena Sativa Stimulates the neurotransmitter 
pleasure centers to maximum capacity. This greatly
intensifies pleasure.

Just listen to what Herbal V has done for the sex lives
of people like you!

“On a scale of 1 to 10, it's a 15. Electrifying. It's like 
a wonder pill!” 
— Justin Q B., New Haven, Texas

“I haven't had sexual relations in 11 years. Then with 
Herbal V it was... wow! It works again!” 
— Sid R., Lakeland, Florida

“I had sex four times in one night. It made me feel
like a 19-year-old again.” 
— Chip S, Beech Mountain, North Carolina

“Herbal V has turned my husband into a Sexual Superman! 
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.” 
— Jennifer B, Beverly Hills, California 

The above testimonials are from product literature, 
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here. 

 “Man! I'm wild as I can be! I feel like I'm 25 years old again! 
I'm not believing this!” 
                          — Mr. Murphy, age 64, Lampart, IL.



Risk Free: Double Your Money Back Guarantee

If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked ! 

Order Now: Safe, Fast, Secure, Private

Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Herbal V  $28


______ 2 Bottles of Herbal V $48


______ 3 Bottles of Herbal V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]

International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       3502 N. Powerline Rd. #525 
                       Pompano Beach, FL 33069                


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.


From owner-ietf-ipsra@mail.vpnc.org  Mon Nov  6 11:03:25 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05502
	for <ipsra-archive@odin.ietf.org>; Mon, 6 Nov 2000 11:03:24 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA06696
	for ietf-ipsra-bks; Mon, 6 Nov 2000 07:03:05 -0800 (PST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA06691
	for <ietf-ipsra@vpnc.org>; Mon, 6 Nov 2000 07:03:03 -0800 (PST)
Received: from oleane  (dyn-1-1-152.Vin.dialup.oleane.fr [195.25.4.152])  by smtp2.cluster.oleane.net  with SMTP id QAA30227 for <ietf-ipsra@vpnc.org>; Mon, 6 Nov 2000 16:09:39 +0100 (CET)
Message-ID: <00b101c04804$03098b00$8001a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <ietf-ipsra@vpnc.org>
Subject: IP.Net 
Date: Mon, 6 Nov 2000 16:12:38 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00AE_01C0480C.620E84E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00AE_01C0480C.620E84E0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

IP.Net=20
The IP private networks 2001 Event:
VPNs, security, VoIP, broadband access, SLAs.
A call for proposals is online at:
http://www.upperside.fr/baipnet.htm

------=_NextPart_000_00AE_01C0480C.620E84E0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2><STRONG>IP.Net =
</STRONG></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><STRONG></STRONG></FONT><FONT =
color=3D#000000=20
size=3D2>The IP private networks 2001 Event:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>VPNs, security, VoIP, broadband =
access,=20
SLAs.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>A call for proposals is online =
at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/baipnet.htm">http://www.upperside.fr/baip=
net.htm</A></FONT></DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_00AE_01C0480C.620E84E0--



From owner-ietf-ipsra@mail.vpnc.org  Wed Nov 15 03:19:33 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01816
	for <ipsra-archive@odin.ietf.org>; Wed, 15 Nov 2000 03:19:33 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id XAA19220
	for ietf-ipsra-bks; Tue, 14 Nov 2000 23:27:14 -0800 (PST)
Received: from hd1.vsnl.net.in (hd1.vsnl.net.in [202.54.30.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19205
	for <ietf-ipsra@imc.org>; Tue, 14 Nov 2000 23:26:54 -0800 (PST)
Received: from sumanth ([202.54.67.218])
	by hd1.vsnl.net.in (8.8.8/8.8.8) with SMTP id NAA04538
	for <ietf-ipsra@imc.org>; Wed, 15 Nov 2000 13:03:36 +0530 (IST)
Reply-To: <sumanth@intotoinc.com>
From: "Sumanth Inabathini" <sumanth@intotoinc.com>
To: <ietf-ipsra@imc.org>
Subject: LDAP CRLs Server
Date: Wed, 15 Nov 2000 13:09:57 +0530
Message-ID: <NEBBKHHKMLFCBHBEBAOKKEEECFAA.sumanth@intotoinc.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C04F05.5A1F37C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C04F05.5A1F37C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hai All,
  I am quite new to this new mailid and so I am not aware whether the doubts
I have might have been answered already.

I am right now working on the implementation of the LDAP for IKE to retrieve
CRLs from a CA.

I have the following doubts:

1)
    I want to know a public LDAP CRL server.
    If there are any such, I would also like to know additional information
like the ip address of the public LDAP CRL server etc.,
    needed to connect to the server and get the CRLs from the server.

2)
   I would also like to know something more about CRLs like how they are
organised, what are the different attributes in the CRL
   and what it is like.

3)
   And I would also like to know the format of the data that is returned
from the LDAP server like whether entries returned contain
   the attributes of the each certificate that is revoked or how it is. . I
mean, I would like to know how the results are returned.

Your kind help will be highly appreciated.

Regards
Sumanth.

------=_NextPart_000_0010_01C04F05.5A1F37C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D990401807-15112000>Hai=20
All,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp;I am=20
quite new to this new mailid and so I am not aware whether the doubts I =
have=20
might have been answered already.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D990401807-15112000>I am =
right now=20
working on the implementation of the LDAP for IKE to retrieve CRLs from =
a=20
CA.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D990401807-15112000>I have =
the following=20
doubts:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000>1)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp; &nbsp;I=20
want to know a public LDAP CRL server. </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp;&nbsp;=20
If there are any such, I would also like to know additional information =
like the=20
ip address of the public LDAP CRL server etc.,&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp;&nbsp;=20
needed to connect to the server and get the CRLs from the=20
server.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000>2)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp; I would=20
also like to know something more about CRLs like how they are organised, =
what=20
are the different attributes in the CRL&nbsp;&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp; and=20
what it is like.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000>3)</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp; And I=20
would also like to know the format of the data that is returned from the =
LDAP=20
server like whether entries returned contain </SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000>&nbsp;&nbsp; the=20
attributes of the each certificate that is revoked or how it is.=20
.</SPAN></FONT><FONT face=3DArial size=3D2><SPAN =
class=3D990401807-15112000> I mean, I=20
would like to know how the results are returned.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D990401807-15112000>Your =
kind help will=20
be highly appreciated.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000>Regards</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D990401807-15112000>Sumanth.</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_0010_01C04F05.5A1F37C0--



From owner-ietf-ipsra@mail.vpnc.org  Thu Nov 16 22:37:52 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25369
	for <ipsra-archive@odin.ietf.org>; Thu, 16 Nov 2000 22:37:52 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id SAA20443
	for ietf-ipsra-bks; Thu, 16 Nov 2000 18:30:17 -0800 (PST)
Received: from hqvsbh1.ms.com (hqvsbh1.ms.com [205.228.12.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20439
	for <ietf-ipsra@imc.org>; Thu, 16 Nov 2000 18:30:15 -0800 (PST)
Received: (from uucp@localhost)
        by hqvsbh1.ms.com (8.9.3/fw v1.30) id VAA07823
        for <ietf-ipsra@imc.org>; Thu, 16 Nov 2000 21:37:53 -0500 (EST)
Received: from localhost(127.0.0.1) by hqvsbh1 via smap (4.1)
	id sma.9744286631.007726; Thu, 16 Nov 00 21:37:43 -0500
Received: (from uucp@localhost)
	by hqvsbh1.ms.com (8.9.3/8.9.3(vs)) id VAA07710
	for <ietf-ipsra@imc.org>; Thu, 16 Nov 2000 21:37:43 -0500 (EST)
X-Authentication-Warning: hqvsbh1.ms.com: Processed from queue /var/spool/mqueue-vs
X-Authentication-Warning: hqvsbh1.ms.com: Processed by uucp with -C /etc/mail/sendmail.vs.cf
Received: from ebsmh1.ms.com(161.144.69.46) by hqvsbh1 via smap (4.1)
	id sma.9744286471.007558; Thu, 16 Nov 00 21:37:27 -0500
Received: from panda.ms.com (panda.morgan.com [161.144.81.66])
        by ebsmh1.ms.com (8.8.5/imap+ldap v2.4) with ESMTP id LAA17461
        for <ietf-ipsra@imc.org>; Fri, 17 Nov 2000 11:37:25 +0900 (JST)
Message-Id: <4.3.2-J.20001117113504.0405bf08@ebsmh1.ms.com>
X-Sender: himazu@ebsmh1.ms.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J
Date: Fri, 17 Nov 2000 11:37:20 +0900
To: ietf-ipsra@imc.org
From: Hideyo Imazu <hideyo.imazu@msdw.com>
Subject: can I have a presentation in an ipsra slot at IETF meeting?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

Hi

I recently joined the ipsra mailing list so I don't know if "call for 
presentation/topic" has been already called or not.  Anyway, I'd like 
to have a chance to have a presentation/raise an issue in an ipsra slot 
at the coming IETF meeting.  It's about secure intranet access from web 
enabled cell phone.  How can I move forward?

Regards,
Hideyo Imazu
Morgan Stanley Dean Witter Japan



From owner-ietf-ipsra@mail.vpnc.org  Fri Nov 17 07:20:15 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29190
	for <ipsra-archive@odin.ietf.org>; Fri, 17 Nov 2000 07:20:14 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04277
	for ietf-ipsra-bks; Fri, 17 Nov 2000 03:30:40 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04273
	for <ietf-ipsra@vpnc.org>; Fri, 17 Nov 2000 03:30:38 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10950;
	Fri, 17 Nov 2000 06:38:17 -0500 (EST)
Message-Id: <200011171138.GAA10950@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ietf-ipsra@vpnc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsra-getcert-00.txt
Date: Fri, 17 Nov 2000 06:38:17 -0500
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Remote Access Working Group of the IETF.

	Title		: Client Certificate and Key Retrieval for IKE
	Author(s)	: S. Bellovin, R. Moskowitz
	Filename	: draft-ietf-ipsra-getcert-00.txt
	Pages		: 8
	Date		: 16-Nov-00
	
IKE was designed for use with certificates.  In a remote access
scenario, that implies that clients must possess their own
certificates.  We leverage off of work already done to fast-start
certificate use with IPsec via the Simple Certificate Enrollment
Protocol [SCEP].  We use only parts of SCEP over a client
authenticated TLS/HTTP connection to a CA.  By using TLS, the client
can trust a CA root certificate it receives, without an out-of-band
verification and the CA can perform automatic enrollment.  We replace
the out-of-band client identification process for a certificate
enrollment with a legacy authentication, like RADIUS.  Further, since
the certificates issued here are short-lived, there is no need to
support client-based revocation or rekeying.  Also, there is
typically no need for CRL support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsra-getcert-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsra-getcert-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipsra-getcert-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20001116142520.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsra-getcert-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipsra-getcert-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20001116142520.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-ipsra@mail.vpnc.org  Mon Nov 20 01:31:08 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21608
	for <ipsra-archive@odin.ietf.org>; Mon, 20 Nov 2000 01:31:06 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id UAA14677
	for ietf-ipsra-bks; Sun, 19 Nov 2000 20:33:37 -0800 (PST)
Received: from rmx325-mta.mail.com (rmx325-mta.mail.com [165.251.48.53])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14670;
	Sun, 19 Nov 2000 20:33:34 -0800 (PST)
Received: from web589-mc (web589-mc.mail.com [165.251.48.96])
	by rmx325-mta.mail.com (8.9.3/8.9.3) with SMTP id QAA08252;
	Sun, 19 Nov 2000 16:47:50 -0500 (EST)
Message-ID: <385476182.974670468626.JavaMail.root@web589-mc>
Date: Sun, 19 Nov 2000 16:47:48 -0500 (EST)
From: SSRA VPN Team <ssra-vpn@mail.com>
To: VPN industry leader <ssra-vpn@mail.com>
Subject: VPN idea for your evaluation
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="385491158.974670468406.JavaMail.root@web589-mc"
X-Mailer: mail.com
X-Originating-IP: 24.12.60.177
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

--385491158.974670468406.JavaMail.root@web589-mc
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Dear VPN industry leader,

We are contacting you because you have been involved with VPN technology.

Attached to this email is a PDF file. This PDF file describes a new idea for
remote access using IPsec VPN.

We would like to incorporate your comments and thoughts into the Internet
draft we plan to generate from the attached document.

Please forward any comments and thoughts about the attached document to
ssra-vpn@mail.com

Thank you for your help,

SSRA team


______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
--385491158.974670468406.JavaMail.root@web589-mc
Content-Type: application/pdf; name=ssra.pdf
Content-Disposition: attachment; filename=ssra.pdf
Content-Description: 
Content-ID: 
Content-Transfer-Encoding: base64

JVBERi0xLjINCiXi48/TDQoyIDAgb2JqDQo8PA0KL0xlbmd0aCA4NDkNCi9GaWx0ZXIgL0ZsYXRl
RGVjb2RlDQo+Pg0Kc3RyZWFtDQpIiZxVWY/TMBB+r9T/ME/IQRtjxzl5ArTAHhKslryteHBTtzW0
ScnB9esZj3uF3dUilNYez2H7m29sS5D4tcvp5MX7TxKW3XQiFYQyghT/WRFBa6aTxXTypkSXdwqd
SxzlXMQg8COhEK5VGS9kCuVmOhFkc7OGaEJbWaGSCwz+MZ3csU9BWDAbhCnbBGEUsW0g2NoNSbcI
Qim8aOZAvgYdKlRLNqDUGrg1PrLBYU/+zgVeO2fv6Fun7UjyLcx+we3FGUXAFako5to18NEH+Qmb
mWlBpjvfSAgBwefyyqUh2aWh4EVKUEnwacik4HmW7fJAwAk1g6D84gah5DJJMVHnB2X5/C97HI/s
TwU9Kf7XrFgADht2UiQ8SyHJBC/y2ENDXiOCh3TazXZtF0HCrCPMVINjKIgx+2HENk2PFhKRHxWz
qjJdB0Nn6yVc3nSmOoOba/S+PINz7D7gH0mX7AwuUCzLG3iGPTg9xZc43Y6KhwhIkoKLEQEPQFMc
catRAo6IqGjVrlbfBin7iUtv102LC+ueul+BTBnMm2rYmLqHH7jfhDmD7XtTY5WR/eVum7hMViTR
iAS3hjwutz8at3q5sjO4GLpO2xqewZVe6fp3ELoUKjZzKUzZihKLyb5GIxxWwWUyKceo7pfgSR5e
vMt2pXwk22cxznPumR5Xy/9W4JOizO8v8OhJK3iUg0qiA9GjHJbEBuZIMdvBdmi3TWegwXsFy6h3
7d62J5AsOCahcUZYmtq0mhQmwNKd265CUmxTA/5a48p6b9O+pL2iWtX222A6vucl40qqca2FR/bF
yaaJWJwC9OAI712zalrEsEaaadjQVrthtrE09loKw/3budGgO0Dvy7r3RSNZWxvve97qxWFiTifS
bxHPQxwn+bhAT8/O44WiZOIoOamUx1iTKqIAoXiuxrTRNXKzNhp5Whxgtu5Y5Uy3c6iajecpYQ7d
3HsZM5/p6it8p2vb4l2vwWy0XZ/k6iUh9zBp4/QuRQmPFW5CnEC9Y13X6vA7Xfjb+pWbiOPCPvYt
PoASLEwnKk+4ShFH5C7FIsarxCVO5P6tfO4fyzH2OMMuGmE/PpJP5jjCLo3/Jcc7/yznicweOL7/
8oQ4pH8EGADU7L6+DQplbmRzdHJlYW0NCmVuZG9iag0KMyAwIG9iag0KPDwNCi9Qcm9jU2V0IFsv
UERGIC9UZXh0IF0NCi9Gb250IDw8DQovRjMgNCAwIFINCi9GNSA1IDAgUg0KL0Y3IDYgMCBSDQo+
Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSA3IDAgUg0KPj4NCj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8
PA0KL0xlbmd0aCAyODQxDQovRmlsdGVyIC9GbGF0ZURlY29kZQ0KPj4NCnN0cmVhbQ0KSImsV01z
2zgSvbvK/wFHaktiREmW7NyUxJl4knhclnb34OwBFBGJOwigsUlNMr9++gMgQYqU462tVGQJBIHu
192vXycigX+P2/OzV7+sErF9Oj9LpmKUTMQc/i+uJuJRnZ99PT97s4Yt76eweQ2/LuPxTIzhH325
GuPndBFfJXOx/nZ+NqZneOoIHsGz9QYW4zG8/Of52UO0GoyuonwwmkffBqPJJNoPxpHGn7T2dTBK
xvxVZYL2KtiwgeUkKuHboxL3it+08LOg/bhFLHEzb+RPXH2ib/wp0h/i/sOQ3hC/0hK98xE/xG/8
Eh9oU/UokrnbOxmPx2Lwn/WvCMOFg+EqvpqTq/SFYVgk4/hysSAcyPuEvXeuX39XmxIuuAAHx9HB
GQmGrcpv3+Tjj0Eyiap7PNxjiEicLCaXYv3OnTrxmFagruGsRbSDU3Pw9TISmd3g3xKRmkXKFGL/
iKDavaUNirdJYdSfA/Be7t1zSe/tBAZiShDTuqD9+FMfcrMVxU4J9R3X+MICF/lV2CO1Vmbr7sDz
88E0Knbi5o4v54jCs3/d3TqH2c2L+ZzcfIgytdf2x2ByGVUuDIWR7oemJ6/BxkhodlViNqAVeOZW
FuSXpH1HdmS07E/L2ZabOyGzjLxly+ljSHfYg6IHGnDCOxis/ADXiE/Lpg+zGfvgIkXx6TjYZScG
wWRCmWyEG0q/qirkZQlgm4KtlEVuTSw6QRsHyQZ5tP7v+dn6H70pc3O3Uuy4i/whz1zEmkEqvSUE
HiFX4UF5YFSB2Fa58jugClWjGfzKkZiQXHJiFe592XcZlTSEhFatMWwrei92ks1MlTIOCPQzxJsd
KWSqOT13QCYpm17SAgaxnY0u1CVb5gqjzvuSLqff5dYld8GW1GdKI3JjLCRGflDC5RfgRqUiLDsv
FD9IVZaBYe9uVy03fIwwM26XXNyisO48aeRWUdbQtVX2a0XhCHOzOzSx+Gdl8Ac+nT/vBpNGnaBl
oQ2MUBUfNodoWAUePESMB4eYEWIjjWB62TQKoC5PXEqpDpSB2AE23XdBFeqgHvgAxpZzmXcjHDlH
s3l6yrtwsVls7XCGWNZhatb5Q0Ukrnx0zjAr8WUymfpOB3HL9RM1NDrUVRBVRXBNTJlCqfrXIJkz
VM6fvTT0IA4X4Y5ZXV4cJ4SpzRuqB8t+5mnGpd1AuikoqMEaxdXqU5hVm8Yt2HCjnINX23qC9KhI
TlDdtKI6b8m/oeWiEwjQBiMg8avWkB85RYSKHXwtFD3emfyPUg3FKkekLkCi4HayEaoZdQnvK3Ed
nFi4s1mYXACy8AucWG6cJHGX01184ZcIX1ut7pdfBvgtFvhdOHOIFRGvSRRawEUfFlqLALBm2Amg
PGO13bY5z3M9MKf7WnD7tLpuRr5YU8gO5tqcG67IXSJqVXXlmlmx8cLBma2zB5JyGh1JJ1c/qA27
29ZxI2UhFb2Rm9+3j7Y02Wve+UKd9EYZ5VLNUben5B6i6aWrtj7a+D7hECp9h+um4Brs6mLuNNx9
mjdCx4NmQu3OVyMkL4AQMCyVkbVZkCJtSRU6s8e4tX3w7YXDyd1bNoKJDdy1QN81O8Dhc0stZFG4
REGVX0ALI1HmL8wqB1+KfkMCkBZ1+UgHbZXZhBzFteIjjdtvjAsPRCfshr7hNdtFkxYPg1nY2rgn
tg8VIIHr/uKFgNZVt/LW7JXdY9FaV6SqR9H8TJp0dMBuYPuS1WUlnwD5RW41slcDhWfPUXGzfHtK
8S4QxEAjjmCOJoQjcXpaMbY848/S5MGIACKOCVKCqtTCOiFb8q9Q2IYBHcKKw2W76ykwRIpmMD5f
ZLKQLiiIW5APKZMCZi/zgaGHpqZfawq+joodivUEj3BhHkEndSVej2GsINM5dY1ToIZV9L/xZCMn
5UvmL+qUTBW51KxU9q6ebObKHnvonBRyzYWyOH1urdKkJz68w/jKdG0C4la51QCClVZCY0pY+McD
Syw+WE8oLr0q0mCzXMkBjZH645mFhlmXqZABxo0cJwYYOFAWtWDr8jo3DSdYAGGZyb2fyCADIUtA
ezECrvEbN+qRgUUrXVjDoaddArmXIXzl9DAEI0wF1TZy3yQP302r8j3kPL15lmXIIJZ1N9J9grg/
l/uR5wqs+0izqLuVVjMOqj3MyTTXecHo97WuUKkxXUhuL3tmNWzyUBTPT4TH/q04f1HUoYaLxXsQ
0YFWCK3npJCVNhz+HEXTkrMUTVPVmDQk6kyxySdQoUPx3s2nQ/H2/jOl6PX9XfcY6CFpKde0KQZ6
g4yIMdGXVEMtKZB79Dki0umMYLoJToYWWkDS1ocT8ix9mLiPS5hOAnUH3SlDXYDahtUMvUfO7KmJ
dc4Cx5iTWYxB1Z/g4Nz4hIE0wgEJ3k3ruHUpnbCJkGEt/EUPOGho/5TZOer9P2lkxbEoCvFRad0s
qHuVveXMVFwI4q09pRxq2b6Sht9g6hb3sm4ijk5cDe7y6rpbrpSKjVjYV6WxaWqhRr4eczlk6r1q
MNeyl7lW7mg2Nrc/x2eOgFXOLjaY5x1nDztW1MMIc9Q1v0qccZzjoWM/7QLnaIu30PZfBqOFExig
DCp2OYSZi0Z1tNJUsUiPxW94SFUzPtP31iNdKSldcqq3OTzU6lkeSogq0zHJJVJyyvFFo7zo9xmS
qb22PHkBETEH74zVdpurtm65XTLKLCZgdBmKD7zi2HIwiYYdshCy9+7jjS+yV+8vBJTK16rcxrPT
5dbQ9Qnteoiuv+dPBUY7h3sgKG8roIF1RsklrdOG3WA0w8L7ZumnGuBMOZjOos1GPT0BIC4f1QZ7
z+sA5lfvpw1LF5PLU3V/A5LFZpLA/DKZTJ4qfm1OM8Oat9raDSzhbtkjFU41U9at+Eq8jUXqyNZN
Bic0ZveZYYfpbaDdU0n/XSybOX3cGNSBgHzG+dBKA5K80Qz73KkoEA5qIuXVuE2xTbn6YOOCg0MK
6cUjuMRNCK4xVVzrKYZqkR/ywGX9XZ0aPA4L/7hOkvhyvJgcF8txjiZw0mh+dRV9sr79wYUv1aUu
dlAuYgt+o+mc9nXKO9g6B699meqTs1INE4eK5P7OqW8HReBznXpd1vhRpyPT9jb3Wr6ORd1VTpXp
qUpEwqubM5hy4RpvmERdyEgvFwIJh0BuDZDzM1BxwvlEGXXCM/HR/yyN3KpqetEgrAiPQLd/Wt4+
d2WjaQdTE/eyVLtO2xwyfSNkh307cnCZUIh0utAykU8jcNvO9BDBz6ab0mxiU55RZQR9XhZi53Yo
NuPJyze3ihQbxj10oBtfAGeXQwr5ditS+z2IME5HHVH2hf8QTX2Ur70GDjlteaR+hyCWaUfJpmET
2oFj1vhshFe45PO/BskclUJ4pOMEGBDENj8o04e8H5S2MjenQtzPOzBaYl2+pDfGx/np/xgEPyd1
BQfffLwmQuPtJRS77pgUAjUUBvXzuwtPiqsPSwI9qUpxGs+T2UXDyQ4Ox4OItKcVaXt5tyZBs8Os
RNuvQLUhe19FJQJwgTqPG/ws4k+FWx9RYfJ2KehvDvqM39jjBs2TEko9Ok3SIm+19J2lJ59pqzN5
FEuh3nhyXcAwI9gw+igV/YnF9Xe6FX4lE2bN9tlsXlPU+lbVwciOLPI6JUoVMIA6WH2A5OQ3mYUc
BWm15bTijG6p66O25RND6lr88El7fMkRWj3oGlu4rPyj5OEFzDhSD+NWoXaoRc6+t1jjd6+QHgyf
g9mejljUS2DWYEBwExGCSq2vUv/IPMCFOkjfhpi4Xp+f/T0AxAZiWw0KZW5kc3RyZWFtDQplbmRv
YmoNCjExIDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgXQ0KL0ZvbnQgPDwNCi9GMyA0
IDAgUg0KL0Y1IDUgMCBSDQo+Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSA3IDAgUg0KPj4NCj4+DQpl
bmRvYmoNCjEzIDAgb2JqDQo8PA0KL0xlbmd0aCAyNjU2DQovRmlsdGVyIC9GbGF0ZURlY29kZQ0K
Pj4NCnN0cmVhbQ0KSImcV8ty20YW3atK/9CrFDAlwiT4Er1TZDt2otgqSZ5ZyLNoEm0SM3ADQwF0
PF+f+2qgAQJUlHKZAhr9uI9zzr09URP4t9+en7365X6itk/nZ5OpGk1itYD/y1Ws9ub87Ov52c8P
MOXdFCY/wNtlNJ6pMfyjh9UYf6fLaDVZqIdv52dj+oa7juATfHvYwGA0hsXfz88eg/twtArScLQI
voWjOA6KcBxk+EpjX8PRZMyPJlE018CEDQxPggqe9kbdGV6Zw2tJ83GKusLJPJF/cfSJnvhXrX+o
u/cXtEL9SkO05jf8UZ94EW+Yr81eTRYyNx6Pxyr898Ov52eraLUgB+mBnV9OxtGy9p7cJV8DFT78
ByM3l8iNIbjRZIYxeUMxwaBsJFCxxOfTgZzeh7PgwKGKA/MdDFkEKv+qbsN5gN/yIn+iCM0hDqM4
yKoyze1rMfPVu5WcCZlEc+EPG7u4nEeQ2UFbXZb7HF0sp9Hlkh11Nm9qR8j6d+kecwcBvwxKdb3T
WWbs1rx2Zi2PzJrMV9GC9z5l1/yUXYs4WkyXtPgxuMk3ujSq3BFScni8CqfzYLMxT08q36t/3n5U
W5iBMV0GGsL7I5zMAsXvaQgY2KmExqz+lm5UUa0z+PPhVukk2eMuzptpK7HL+JISOxCaB9p/B6BM
KTyK/9BPZdQG/2qr1kbttE0ySO76RxjDvIqmpHartKJHYcQlE4K4ggR48/FefQnwNcmRIbNAp1aB
D/RsmrW05AAgMvT0JcTfCMwDEj17AmQ0/x6u2G6JBPs/XyzI/0dZsWUHkVE8opGwgFLAMYxNA/Bn
lwtUjC1pDruMB+yMhQkHnaUJB6c2nXZMeY+U4wZZlqgWNCU/pAlEkOfkbqHSFcDClm4R2BJ5eFgF
mo73XXv4B2fR0XODnIQ0YVKApmAhr72ktctAJek2LXWmNqxd7PsSbY7Z5hnZvCKby1zRV47VimcZ
GlK4J5If0MgIJJkCaLzKeUJBf9IDbJTx2ZjpOYQZw2NLyD4qhKGFVW0J2dTxztMhB1fM9ZPZH0JY
sY+Uv+CYn6Jss8UpAvwrHM0vJa3WlBjvOjP/BcsBYNaYhKMPkaEk5daaDUMEF6ThFAOibQ6J5Jz2
b3VBApDTCGTEQrKBQO08q4K36KCE+cJm6AGEZ3nO51SF+l9lPOg2bEUDEsOve6loHQMc/BuSMoER
6n8QRuGBP1GdNK/V57sbJqwfDzxqiLgJ0jZSH4RzT+4rTduFo5kPhsegTUQhlT7oNNPrzHBY782A
OPBbkaXsditlQmWRUZrYCCCrj0jkcd4G4MKxNl2+PsJ5Ynj/aYiuNXDOnlQ7a7Z5mZJKeFn98Ntb
SdJdOJoG765VPBuvRENPswSHB7jxuYWakuO7sylgy2GIhjgua0iqXucHA/61PSA1KysgTcaeemWF
tykhjRycHezSJCivStHOlKPfQr6j9qOE3lINgCK1NbWaF1BrQVuhQDB2EvrjoM2aC5QT2vZnRnq2
I0D8gspF9YPpA098yLUZLgkcAWGWxTzWcetntWZzHK4SxEmnZHBjMQArFwmcclxW2mx4ps7+fSgJ
OXObeP1X3bIM9KLH+v879djYHlkNSf4E4o0NKXbb+0wXBWL1dp/ykC5RR4y6oVbro2uUzFCrtBi/
rFViOogzitOU+uRfs9NaMqcys9U0IkLPK7BUDmgJb7PTgI21gRLVsM3AIp8oCvBDH1wU+rHkH/mX
sK64PhIApIkpcnGn3OlysFHRzZZo4daqLN+44pGpytZwft6mlooWeS4q0u2jUssYq6sTHgyh8A/g
QrOGcPMeTk7BjqTiec/IKbeBiILMK28lVQSou45ljckBK1/UcORl1LliS1kdSeEsuCreU2wrUYgJ
FUJ5cbIxGatdut2NCBww2xxMppoe2BT9wWTPbIJuMfKvMRS3ryBFXIs1L2ns2HgbMVQ4Dernyp9K
AMhRxTBW/XqeaKgIWnAGle7m6qP6EseTa/iJo/4NG0P8216rD8LV8J09hpcp3Uu8s2BsRu771xu/
uFhsdVSW8tiQZPdtHYEP11EHoe68qCkqztUrNJagNFhmam3mXbc2/X84WTQUVv1XLmfdDcyDw65r
p7VrLwXWoJ49dcAno38AXALEIog5R9/t564Kw71PD2pO9XRevJ5p+zBszA9bh6VlUP+NqjZzSWbS
zXIVyAULYfGSGxWvbZdtvmpR95mWdFGKcKn6XJ+A/jd3o5LvVcDexL95Ddh5dJEip3qCPBS9C0jn
qT7O9eCNAIL2rbmIYaUSFMdXhGWERofCV2xMKY3XsWw+im6SGHtd70WHIQJAkbHWKQ7Ql5fRfBFN
Z9E46ixu1SQEzbBcOI94537ZOtoOcu7sUy1N+3B7oSarOIpnsME4WrVNnU2jVaTeGy5opl/vnEIL
1WF3PK5fkJptm/LF7YtLpGi6pbeMCiLsBk43Prsexb/s9HGZK6fvnVROhIFYXdYNS2/qmd2cfzbj
KPZ1xZy0qmmnnE7rchp7bRxdMaE1J954HelzDWm9Ie09kx3fhksSl2QE8jAHNsyBS+AYtJ3MLPAQ
xnAKUn8OCZzL3QBK29/qRU90ZU3lkg6Lxc+p/6vC68yadAqK5JJF0MhSTNPGEfy5G02dT63u728a
YWj3geBwUzzLPNE10fxOrwvftba8hgqyQxEZw4wTNAqIqWn5YEVbALaK224uk5UtvQb391wahVr+
OFA5qjEotLey7Y2CRjtzMYBE8mDjnHGVMbvAe8qSA8jbZaZdRT1loN8LdV9Kmy+dLDj0BmZduC4n
k6jXVj+xb/TetrbuBHUmeybNzQ9nrak3NFavM7yKQnihmov1lqfWsvbU2bqzpe/VYOQQB3CUOqSa
yF/3RLRXwRik24B1qmTKyL+JcBe/3UqbgbUqdemWgJUloheRyNuDlNADpgoKlaqvH93Gt78f8Cq3
5PtYwFyf/05YZHNLkaU4rz0y1kw5jaA6WOwSKkkmJdClrrcO+ULRaRFreIsaQK61K4LCoZ+k3zV1
m9mq8d1wJWn7CCIltSWDxPHahCPSYZOrCkZsmXJ+o15VGNT+U+rN84Pr3G6y6glC+dqtacvvMj4p
vzdS57O6Jrp41GXR8ZbLq+C4zJuridrpA0qgNJEIUZ6VU/fgoysVPA2chUkUiqc2MQVklQosp2og
xv1CO3BECeUly7d1Pu5Ma6/u/bDLuAN1uLWMEP8M612a8ZeUNywy45CJHQjaggQod3lVKvCL+FT5
OtQl7aMg3YpQbisJPSTbaQhvSbzVycGPVb8k+n2zLeXTsXL00fnilNU9otLfV740bmv++KIGwNX+
WjL/cv3v86OduX6wmT88arg+pmRq5VlXDW9ihhk0ztfvr+D3/gab6NvbW2XKTVPQ64shWuXzzeW4
3EnLW+hCOFZkEFzoM9FqGknRK9uCVaufeMNGyx1GJUwMsoLXr90NTq+ByRxF12W2zbm/v7siDnca
OWlySA2qpjzUpbnGHdWBxJTQaUR+9WpJ40lllM/t/Mjg24fzsz8HAIi6ZgMNCmVuZHN0cmVhbQ0K
ZW5kb2JqDQoxNCAwIG9iag0KPDwNCi9Qcm9jU2V0IFsvUERGIC9UZXh0IF0NCi9Gb250IDw8DQov
RjMgNCAwIFINCi9GNSA1IDAgUg0KL0Y3IDYgMCBSDQovRjkgMTUgMCBSDQo+Pg0KL0V4dEdTdGF0
ZSA8PA0KL0dTMSA3IDAgUg0KPj4NCj4+DQplbmRvYmoNCjE3IDAgb2JqDQo8PA0KL0xlbmd0aCAz
MTUzOA0KL0ZpbHRlciAvRmxhdGVEZWNvZGUNCj4+DQpzdHJlYW0NCkiJ7FdLcxy3Eb6ziv8Bp3ip
0o4BDAbA3KKHrYcdRSVu5aLyYUmOyHWWuyxqScX59ekHGgOshlIqpYNjb7G0mv4GaKC7v36MUQb+
bi+Pj75/cWrU5cfjI9OqubHKw7/QW3U7HB99OD56uoAlP7aweAFSbLRTGv7oodf424amN14tro+P
NL1DrXN4Be8W5wA2GjZ/Oj56Pzs9mfez1cncz65P5tbObk70bI0iYR9O5kbz43ChaO0AC84BNrM7
eLod1LuBd25B3NF6XKKe4GJeyL+IfqQn/lVnv6l3Lx/TDvWaINrzE/6ov/MmVrg9G26V8Wmt1Vqr
k18Wr9ENXXJD3/SeTKUHdkMwuokhJD+Q4WT1TJ0sfkVhbhrTeXDU8wwuHu29d656/7VNX338k2r9
3V/w92n2mOe8KdhImyiZrSRzzuZXG4Up20LKtrPLu1tKXFDw/M2pWm4u1JOLC8YgBeOMfiB/6X9M
3/XdbrXdqOfL3fJsSeiglkkJZbmbnQ0XF1AKVpvdVv3j7Rv14mQeZktM/eHTSU9Pv51Y0f3ksXqq
/qKeNfvp6mxjfWcU1SRDJk1k6Gj9XDagE7z+X5zwWL16q5YTDiBgublkTMXY/Ise0GEhiJDUnJOv
NrR0dTHcptJ4Qw+r++Vu+Kw0ceRsdA+ZWfMhmXI+2ocr3y0vr1Zn6uXdx4/L1WbPO6GBzdArCm8+
4Bu1YiPJDCrgeG+2YrNbU+gqG+/Wu9XmknxxxZRQRitaN7BPGNyyy9WbYYc82NKrfwJloGCfDvVx
GJcdHzWQd2/Yj6thc86kQxW06ip5cy4mYvhjIBPfz/jMLXckPiDdZgO3JZ0XxMoUPEqB01fPaFGj
Xg7ZJo7fcL/a3hGQPEGmyLXZGgh2cbtn7M9zyaDHmBTDjk6acAXuAm+yTXXY3/PVseGl++7ubtJF
pxnltHuYMO9nr5dXy82/T+YddN52dqZ+AlEUjcRpXe++GXFSjbhZb5kgF9Dj6cW70ydfYkEKwlK9
5TdMA1xwsx7UD5vL1WZginydiJkvbFnFFyHpaXogZ0vZYltwdLkY7of19oaNAev+C5Z+iYmE0Fa6
LU5Yu+0lV52bK8KaihLSLspoLuCAMLsCDt/trraFvfmWULnB4cuz7X2qUsuNOhu4ug1LQq5gwf1q
KXFartZquctH6zR+Wt9oDwfrkZc9/9xSsZ/j7/3N5q+opQPfgRNX6+YcV2xRuGaNP8CcatRKHR9B
KBqPtRS6F5TXziPjQhpoH8lEa/TkLOfaCDFUITatN3sz7UQxxVN5wbsXeP5rUPor9BmYoT8hY/6m
3v+i1QWYqX3jnHJ9bFxUoNaaALfsdN84tRYRSISj5MRrGxv/pe2tw2uz/OD2zmp0x0OndxALO/WW
7/7wbm3w1g8dfrr/EcHu9jBauyZGWAjlFqvLNZOwHauL1IOft+dL+E4w3Uz9PNaVkPQZSwrhP9sa
dgMkpH9oEmemyOeP6bums+PlUUZXGYua1gh4DGdn4LIiR1wAZ1gG6GOoMz3iBPR4fGdt6R3rkkKr
LSlA5kcGOpBCE9JrYm5n+/wa+AxAq0UB3A2O7lrDkkPigoTUGIMJMq+GsFlXvreW3J62265xpXK4
SHU6vNGxvF9rSd94/dbtGdh2mG9iP3wfYkyyeyykmC0daFs6LHsY5c4XIUAAPTCynRcAL2MsNQCh
bHWGFifwJRxExhZXdBDL3hZGYAJWZrreondHR7jeYHiyp1zMdpEnHZScpIH9jIB2RSRcxPGiSPqY
HcGhLBdQpAsVzIXiEGZLcQsgU3FH5lphBbNxtDORdfREonN2lfBdXCn5kH0tGZOjUaUUyGePHq4A
GHbdRO/2ay1kfxgLQSeF4MmJcbM30ArVd0/x8bsvFAOIj2f9EOoHisHUnTSTrW36z6rSzPRIC6gy
gCUFU2Woo5QEFaEsQ5MFSEPT0NA0IDbBS5FH7uLeeQtOx8b19NGX359iJ205jSwmNK6sdz/8+hRN
DK5X5S83Z+wInaGIIxfhREhzoMOo9UsrSHF0QZW/VHVTp2QFdC3SgN3DRyxfJqZcj4bfiwytGZsR
r1/vK0h0+/ZaT8uYsdWYRJ47Hq9OwLoCUp76jhNxAkg1DAC/JztU0YlEaZolKk5dvm5HUqp+npQg
0HoBPK9PPcCncpeLOLCj54KYahEAWGl66v0J6LhQ+LzFsY5aDlKsALAkd7aUY75ES9UNgGAroC9u
5bgW7d2qlwoJQNxb0Nui0IuhhUyNIEpBBAAL6BQQszc7vmbtzEIOvrIruT9m93e1xMGLY/A4tiVA
oc9EoF6VpcheFp4kqk0AQjWf4lDLQtazR3vYgdEHRv9fM/p036/XpV9LvnTQ7bUr/IiAjYXbECi9
hnJnC7chEHzhJgQy43FwKnyEY1TlEgRGL+LYXAFp8nKlH8apFmSagwvZ83uhH4WoBlylgdrivjga
FPlKI0C0LO/YU+OsAF+dgA4fxaDZqVYSImj2qk10Dpp9aCUfgqkldqNNYQyGLSxkx9NbCmswbEIr
HxMAkFdHwLJXW5kFspziHPButdwy4PMO56aB4GsVYf/MxBQB8qVpgKxNyF83YqQTp4tXXFP4zEnQ
xaVO8h8Az8t7XwWhG4NAUeqkCAXN2dLlKsVh7XLpTGHvmiw73pA+sIQ5PudbZBt9k+XoJuUuczfY
acDnLX5Czlb4wI4ogeALu30QM/MU2LNfdM7AZOYIuMqVPBBXsq6cL0XCFb2NoyGSK4khVShzi+pY
QV8udJgBfW4YjlPEl10JgbGl6CoJBdDFIXZSdpXGsVZmYOyUzn0OFPU3Nd/P5fHWqYB/BjAHzx4d
yvyhzB/K/KHMH8r8H7jM4zAfevKOsRjHawaQyQysGUDvAiC52VPMRyBqkkSgTCrlllcnSwFwfGLy
PwCBT9R5CxLXGAlINORdAKLIlsSUSyC3DKTvz0ivEGizBs8adFaBshaWRToMgZTzka6DgBfZ8g5j
S0D3QrRoiXh9dovIptKgYzYrAz5roA4ai2tT+gThfrIDVox2JMCWrgB59M2+rOtDMxBL70/Icm2O
Fxg2xsvvyS5WljMHKsCwikypGGs58AbpGMzKKWBkZQpHDWQi01BzoPuB7n8OukNxx+YTVPl7e4kr
I3UW4/FS1wXfYuMKF7m+lZEwcucx+Talhpxa31wtmGAU/tG1K3JcF1wITQ41dcyQKctcCFXcfeav
lvEoVIk5jkcSWF/nNshjbhvekQNdShLmPLGl2jLOdBJWGfpCL+NTdlE1JIbABxZAudrLdFbLeZwL
nnmWLQyeLzQB5B2utDh4pt1oo+ccLgHtKqM7GQGjyNWgGzr+BsuTMQBp8nVZgy2HztBxKPOw7TiS
eaYMTuZ9Gc+dzPsywDsOZZ733d78z4J8HbQycY5ANWOCbOM0EPIO8lMJdPxF40T2rpRZ0K66X55R
xaI8o4rNtnCjLUdUcavJTun2PnYlUvlTM4WSPpYKNhhJMGGLqdilsxMS/yaA4CtgvGRo/J4c2e6q
RJRymt3bDPTVqC4pZTObUuUcHZWSMAOS9+1eh86xkVqSP2hTA9Z118ofKFK6nDgyddvxC1N6Y6Zw
6qaZ81nucnftqkogQC5WtqkyO8tj+6YTQy0Jw6U3TwB7NoRxYkhy2O/mnwGchdQ2DmX9UNYPZf1Q
1g9l/Y9S1mFsf7o4Pvr+xxZG98WH4yOvNPx5ZaPnDxRYt4BSrwnH4V43Gm68OD8+muNjpxafjv/D
erXrSJIbQV9fMd7NGNcoPooPUwIEAQtB1nmCDBnnHKYdQYCgvxeLzDfJ7sJBzu42NyMzopgVlfmH
v3/+9Y9fLn7+7at+fvz0p+ufP3385ev8/OdX+Px3+/vX9vd/vnztB//9+scvP66qGaq2Zr7St79C
cL1uwrJXoaPX+Pz4+uW3Jdd6gEcXD7BGLHTop2s7jDse/myPF/CLqj6hn7W75MJQ8s+/qO2mvTwt
KsbLqa6v4OE/4ungdQj+ui7xO153MoK/DRi/q//PhH2XLH2L5D/XtB0kGmmvVY9+/B7Svzudv+aF
JjGWx9hGr89lgd/f4/d5/T+1cQP4Yg4oAzyEjx/tbn/7UOkan1b64+c+RfzrV1hbf7SLnQOByLX2
RnxdlkygMELa26kQE9XS75PF5ssPhNh8WbMGxG2GWaxQ2mBbqVSVeSdLfOIRtNTm/AoxEa3jaZHU
+jiU1HJ9CDUgbTPMUttn5J5YqsvMSzTUJyanFlsfRSHwNwDcwdf4HL+91Np+u7QCLDNMWtt/xjst
zGWBdzs4lNQtEYY4Fe9UsOcrHLHjzkmmG00yAZYZZpnukW7JpLLE+frSK9obIgzxvX0Ygb8REPgG
IV65kvPGCxCwzDBL9Y9bpsRlmbc2pS0RhvQxSUICuBQiojYlF7QpuWDMwEXzrssMs9YgWuyl2GB7
MRhbWjHRtuSitqWZ6qltyZ3allw0ZuBOY0sywyz2fBz3xJ62I6OxpS0ThvSFQUJO40tpPC8Sm4wv
JWsHyfqSyDCLTaLVXopNtieTNaYdE4bka+2RkKzii/GmbLwpW0so1pvKK2/KN70pW2/K1pt2RBhS
rq1DQooxp6pHJleMORXrCdWaU30xMnG6d2KLbchi3WnBRI9M7UAjLFV/GHeqxp2q8QR/mFdeZpjF
1rvuVG1DVutOCybanfyh3Wmi2jbSXqQ/pec4iPgbAuBNgkW0bS3OqwOZYh6bMF/LclxVt2OTCHyq
wrDwzkyoMELO0foMmbim0fos97w4Sb0nvk8MCfscs15K2AW/GP9l4FNVZvYTFY2AhYERE1fYB1hv
Gg7OemkLYci5z7Fad+o9vTJQ713MfqLi9QXD2sCQiSxsBSy4jBZgwbSLMCTvcyxWHkz4TrAM1LsX
s5+oRC0YVgeGTGTHZsB662gB1kvrCCPqNsVq7Qn35MpAvX8h9wUTpRa3B4nQVPt6QFpb/Km08j5C
8cYAOMFq6TlvKVWBevsC3gseKt4Zn5pp+odXSp2xKV5JGBG2KVabzz2XUoF6BWPuExON8MalZqqB
vzmA0CbFWwkjzm2K1fJzz6NUoN7CmPvERH22cIVgxER1bAysNhqH4rWEEXmbYlYbbxqUCtR7GHOf
mCSFiMafZqqn9qf2W/sT7yWMqNsUq/3nnj+pQL2IIfcFE+1PyfjTTDUrrcn6U7K+kO2Ln/dK011/
SqYlE47ASHumoeKztaeJZTH2lK094fbCgLDNsNp9brpTNu2Ycf5l5sacijGnYs1pYlqNORVrTuVR
DODcZljtPje9qVhvKtabivWmahqhWm+yVNt4Abuij2pm6QffYgRL1+ohZxZ5wDnmeYISxjfzhAx8
qsqlbKlA5UjjE3ArZUO24r6IgmFIYcEwgklI2udYDVDHPcEy8KkqM/uJyqkFj4mKEZZrm0yy0ouj
CunFIUxCyj7Haozyt/SqwKeqXMqWSlZ6+1wl4w1T96haLQwrrBZGMYb4cQvrHKtBKt5TKwOfqnIp
GypUOdI04hVi4hqG07NeGFdYLwxjEuL3OVajVLqnVwY+VWVmP1FxWu+YrRgxcY3GrnBgYb3BeESD
xH2OWW+4aVcq8KkqM/uJirYrmK4YMXE9jVvhyMJ64+gZCUn7HKtx6p5bqUA5Ckr22q24cqQJTLnV
zDVZt0rWrWC2kZCyz7Eaqm66VbJulaxbJetWybpVNvGGabZula1bwXzDkGIdIL90q3zXrbJ1q2zd
Klu3ytatinGriWu1blWsW5XRMRLi9zlWw9VNtyrWrYp1q2Ldqlq3qsatLFd/jEfGeqt1q2osokHi
Psestyq3an9sBVdrV9Xa1YKLtit/aLuayLYBDd4ImK0SPkMYreB336IA0J+pPDgEwkxWlK4Nsce1
Mvzcn85itKLIRExGbx7EpE/9i8KJBmG4zSNuuJaxJZFaGk8JcHoD8HGXYTU4J6E27cVSIFOPhvlE
BOoioqDPHDQEBy228lXqWZUA2a8AywyzWEr39mopkrlb6msmjKjoMgiBA4K0wTJJtTyYEqD6FWCZ
YTUyH/fUciRzL4b6mgkheEg+aODPWq0bT4zU0mBKM7PzBlDiLsNqZPa3GpkDkbpTvHc0OJ7mY4ZU
LTVoh+KZlMZl7QsIWGZYTcs3HYojmbtyqC0TRgTjUDhPMyTyReoRlQDaGBCwzLCaldNNtcE2ZdAW
tWXCCJqNERKNRbVpUlkUz6ME0MaAgGWGWW28a1EcydyTob5mwgiajBFyWotK44mR2qQtyp3WGJK1
KJFhNScf917aZNvyfFjmE5FTfX1wbmbIRDUbh8rGobK1hmwdKr9yqHzXobLtyqx4L2hkLTXjusYQ
TdS78d73aROmrl6zH4yxq/3qgzLE98aQB5xgksrZmnc0v90OjCoQBsY8CqUieeAvN1qY4ttBMQFJ
HRy+Vzj7u3QhgjwAiLr1il8yPT3LZ6dfEpFgOzv3S+/kt7cuI4GIcd5q7AsvgSDwNAgxUT3O0Qi0
LBxR77HXAbw3OG4ns2CpHPOMFcfj6vN857e7e44MCbmAYBj920FcV0ZEwgeAiJlsv2qucIkbB6JC
JfyJ/UgHInxSCsnerIEqUAqtRmg1rDF8JoUHfEde6Ty7IwidZ/82VPGcYjQHfq+U0r1TKgOBSCyG
eloyR8CCWNRa+94htKbu/EJreuiSsLnIg7jXSuneaZWBQCQVQ70smSNgQSxprX3rEFrHSiW06oKw
tciDtFdKyd4plYFAvJjCS9YYvqBVlE5YFlhoO7jeEBaKKwrlwIVDHuS9WE74RmwLdJo97D6y0LFh
D5C+USyYYvzYF4Ra198SodaZNx53Dj6QOVbLULyn1vXxVlIfw4UspL2GKyNk7BQLrogI+EhRr+9v
itDrzVuPW4c8cC/0UsJ3emXgc1nZG7/hyggJjw1XRER8qKg39A4QeoN583HvkAfhhV5K+E6vDHwu
KwfjOVwZIVF/O5grIrLt52z7OY8tinMU28/5ZT/nu/0sA+UMLwuFtGaPkGL6udh+rrafi+3nMuYu
zlFtP9eX/Vzu9nOx/VxsPxfbz9X2czX9XE0/+8P2c7X9DFM75fCH6WeVYzcl39BbbT9X289EZWIP
EH88NlwRMaZm1tsODqW3QarO4cy3X+WY9yNK+EavCgTy+lvKVCb2Ua1IC66ICGJafI4DH5XeYL4K
7cDQCHriNHop4Tu9MnBQMVWAx0Sd4u3NBDNrAGRsrkItrbJUhZddyCEPOMdO7VhSb6gV22xQu+yC
B5T1Wq2EGKYRpxdUG9EPHEUEXeUc8806x6yWEr5TKwOBilfkJyZUGBFn9y4Bmbgm7BDUe6JBOJJ3
egPx+xyzXkr4Tq8MBCrRkJ+YOK03jY8VQyau0BLXN0s28/Vb9lC+wmSHyAPKsG3l/hG508o9kFo5
X7V2NKAqxY9WlhBDFLqBpEI/kVRoHwZAcywzbPv4vVQZKPqYmU9EqC4ioI8ZMlFN+O571cYkFnpH
Avw2w7aJ34uVgaKJJfOJiNNioYkZMlEl9T6qq+0H3+IgkYvDE5QHh4SsLzePD1Cr++52M31Rxu0m
+qDA7S4qR3rP+wDFEEu2DWVXwImP6MgD0Q++x0HPGa+XAsYacyBSTHI5X/ONtrC1K3wxQVLkU0x/
5zV4LCtz8nNY7JEeCjGRx1c5PaIyqev3t/h9Xq/JtzADeVAEYm1S6epEvNx2snepdD0Rcql00ZUu
tSibqDGPYiCGKXQDaaXO1Z0sAW6bYdvIN7RSZIq6kQ9tU4vCKZpGPuKGa+KblDZFasEdJsAyw9am
bqilyKR8SlJfM2FEGnsAQ8C4GFIeNEp0RNaD0XVQ1Ne52C+8yDCrzWLceWnK2c5FeYz0PCfMRPQo
UtDWEUAHiKiwJaHWqoeidmDCs9/hZ6VVDDovlVY7EZW+AArilkZS4RXnYQo3A3I4YDsCne13UDrb
gTeAag/KVimne6NUBQKRQyldECkK4HAWRoAzwzELg/hTK3UPE272D/VgjE5K9k6nDAQavhjaK9YY
7nHQxHBvR+LywElJvqQ0OY1Xg4ePYgcYxm9f0fdzU7YjH7yiPAXNPPSgBW8kA+gAEaPZSWj9H/tV
s+PGjYTvA8w79M2SgVGabJJNHvYQZ5ODERiLWDcjB2UsOzEsyxhP1q+/RVYVWWR3S5rd9R42gmGN
WGL9V31VrBY+7Ax5edQL3Iv9ed7N0C571J/F6tYKV10PvOTn683WT1XOTnKbsJPUFPJ6aAl+yc0i
7Iyb1UXZnNnuGTt8xaB4SWQG1W78flPvwCN7oquCKXsnFa4knNiAszhz2XAp6yxVbllnp4bU+6/n
Wezr4VI4sAyKr4Gfh1pUjbw+6iX+xeI976m8KIu3GN6a4arrgbdDXw+XzEFVkP3kOsp+UtlIhtAS
/KKnRdwZT6uLsn6z6TOG+IpB8W7o6+HScvAmyCp5EyQFeZdiTyXBdwt7YBGW9kC3uAaWi840jvaL
dviKIfvV141atsDQ7LyeX3e5T2vPgMH4JQnT8s3iwFeYjcsrr7xYN2q/bMlQs+SK7Y2s8RIezaY2
W4NrtoYJx7yIj0KELK76ndHInF81qOrB/jsVYXamGkhzUdTaptIj1tjUNwckxHpBQrph8IEXuPDh
hvMNociYWFsEnunR6uIBNXtTKcoEarmimVnspjWNbGUIswnhir/wCKzchbOt3OVnUiFIEXPv0+yE
ir24CL7iIhkSO9f2S2ZUl/GpxpcnJqaBJJzEPhBejnWceJTOSlgapedTWl2UHRqaURrqUSoYaHKG
dpSGeigJX3GoCV9DxU+jVBKWi7cIu2yUVob72tMwa3UzSkM7SkM9XoqfhPTFTwL2ICZaaAnLdVvE
XTZKi+k8YUIzSqeWN6M0tKO0cOjKU8Q74SmiY+Gnd5ogLPuZhZ3zU16UIC3NnrO6gVpppZ7cL3s9
gXre69WmfgZkKM+Exa0+izq31cuL0kW5pM8p5evZJr7eGNk0U4+TJK1QfbyyNNjpYnkl9fQowtaQ
cha1kPcnpqNWCEZFjaKdT9G2oJrFv7doByetNwhGnDQ4V+HqHb+SmCAETCwv0sCek7Oj3ByyIXXi
JpZkxczheCNmjomtKIK3vH6o91k499VSx0ZJwuKSV6SdWfLgYr6XzNDNwgaE4Bq1tmYx/Krpc3DG
mkXzWki+KuYgBjVlqDdaKWHqbBZ3ZnsvF102xNXezlhCiplFb1wTn8ZUKgXLZV/CYUwVwbT5ydoo
BCljsZDT8nVRIac9ThZy2gVFEc1oZg4q5MKxZGzOrq1yFc/1UgyEpqSEhKm3VrwpTmbXtqmyOLdK
rmYsIcXM4prn3NTWEV9FYxRFLM4zgQJk0Q4aRMBCz49CKDKmDmeBZ0ZodZFMMaYC1BlTSDOzjJua
o7VVeVxzOLvKsw7Dvw/VG1CF5j0rJUyfL1ncmeyWiy4bUiV3akjWyxyBH7TM0pra44C1acaJEWx7
gvFo/MaH9C7Mnw/vIxXufU1jz6UNeOyj7ENF0PnJ49LZ1Eer+RwRZY7gMseALLzuulTpcwTOq2cj
JgQuDc9aCiH6XuwoBMNnVTlGBGuFkhQ+28gEQpEZXZkjZCXNcUQVJZiqJZAKI6M3cy7hRQ3O1OcS
y7HyqsowEH57fk37XzDtCZ/iP+x/MAf73yaUcfTw5BNPByBEzHGeX1uFYEiPSbjlYgToHGF+5kyb
pOpZRyGQSAp/qCXC2UuN+Tzk390cwcI2KwXC2TqpcY5AS49K5VIT8MKg2S3TEuLwKhzkeEXwUilF
ThAsW+F8Q8hnhTpoApTs5ca+5vP/JZ/xZDUH4lARsgIzdxyzNI2B9KYhBFfrawmB92eujxmCltkT
R+fl/ZLNkLNpXUMwRppZCPnCoKfnEmhimCMMWioFQmXmzLmXRWmdCExK3YQwisBQMieEKh0z50GL
/M2cSz3ZtsBKgXy8bN/TqBReVrhlaoyUIaOUwkmlcs0OOFgKQUjIqPPflvpazijgTsMwXTkgd5qe
OgaYbnfxX/JVrOsGtUShKRl3aTOO6/qL56d/r9d5NjddOgiHLFkQCWkjYI+Bw/j6PEoGkP9ie3vz
3U8D6Ni+u71xyQHXRWSCEW4GQBMosO0hRqKP3+5vb96sfli71e/rfvXH+k6Z1f3arHbvj+tfty+j
rJFkgWlRGPzRw5CeiCANFoUkLAladevth1n1vUk1pQGTTFE/IJcK8YUBvsO6RQLmdKbe0RHlJhp/
3OIegrnSo099F1L7wd1B46M3UK8P8CyK0Qg9NcVg8RnpHV9ItW08YeqgcHMKlhu1UkEFC+ujCZ38
TNZ45B0Sgh4EgdHN4047BO5Aj4ud4S1L+7SARQJtej6tbJGQL+CRFjePKGHyzutNyhhEmS5g5cCZ
YN1j9QOBPPQadWpGHiCYdCYGhU9LzZMLCAMS2I1U95Hg+azxTINpDOjFwH6OI3IMm3zW1dmlMoIz
LbCjjUVRnXsk0EY7mhRrQRhijCKBQoXvgprQG8niEPcFATfxotZVRrhxI412WFvlbFhhnwnay7i4
ATk4cHCuAus06s+hd5ojSwIUOplzBwTtZXZdv/Ey/XA2RtSHDVwfSjPBeFlRQKAipbhZz0Vq+Ew1
SkULBFuVNRA0NkK+oKpGAEJMRe4UPufNkyWMwoioAwhWSyuAoCu7B7fx0jE428p1IHB0MTaDrYMH
Z1otKLpAcDL8cKZllPIzWLYbMzpYmW5EU1EQQHBVCQGBBgOWmDjjr31Vn4DSXFBYwYVANQ4EL9uk
nLGPBENqNHHGTiw6qVWLSdTLhUDtX7wifCh+E4JQWAhgIGhUgghAJYiEUCXMhGE5DwRyJVGEgiWT
Pm3bJdWEm6UYCIpLPRU0ZyskvPPqcsX8K+ZfMf+K+VfM/0tg/utTkC+5GrkTza1pE9sn3rXuT+LT
BnAS4ToBk/y0GZzkeFoFkzppC2lSaW0pNqU6qeVptdfN0LbKpJcm3Tbpx6pbJ7086fYWDlq4aPFk
gjhzmFSD1gTVZnBvgowT7CTCWKOrEkKTjH5TK+kFPicz+lg2YgYAQUu7dRCuRs90yErRdx1y9DA6
OojYac9Th2ILhLHCWu3z9MX8ACHPxqTA53ynbGqfCwTTrUcuMMdnOc7LEX/jwYrFJwhYntqxx7Rf
CILCEDiuhzFtAjUh+VRYsEkqQmUGtZkgYCNmq6lT85l6OztNnV+iQthQwobgkcNK4FLiTuhTMkP4
VHJHCEaZJcArlUA7ba4dWnpLcTFm9gKcU5vkgn3a/n0F4ysYX8H4CsZXMP6fgDEsxi+2tzff/TR0
qtu+u71xXQ//XKc9PTYh96B0Cxjdp58e3sO3Td8P3fb+9uYufgXOr7c3b1bfr1W/evv2Yf/lS/fL
2q726zu1+nL8CH/s6s94ePwjfT9+6v4Ov+8Saffb7st+/ev2ZTRjJDPAjagM/gxQL+nJOsQ4oh1R
c5+Urrr19sOc/YNCKHebsSfzwVKTWN+s/rFWYNnarPZ/vj2+WrtoulptT1hheNhAZIsRi+pj+LiN
Tas/BU1T0EIAkZuIxt1hPYyr3efP+7fd47H7OdkUjeuepa/PTgcpQcLGXR6ibCP0vz9pI/TGKRtf
xI/u2Q9g6gU26k2up4mRP26jDd6MnfyMJadAu+6sSg1+iGcwyAGBm0eBhWC7JAzxG7F8bETQIvIN
xL6OLowmdPIzdU33EiLxoZMsEHcVIo5AW0DuHvbQj8/PXEgKXIpO+UwxAgUKFZCRfULSQ3GjH2iG
X+BXJYPj9S0EL4KQGhDh/AjFdyEI/Xy83yHiJIx5Bf9fR1zq0meCpId/7h+W61QBCkcU9XESXNxM
CrNkYGxYATgzBt4fPz3uEAc/fenQ1GM0K9v9aQdd5lZ7yPY8ei4br2NQkxXDE5BAAXDEAQtj1Z5G
q9jjv6/7VbTErO4BQXfvj93f1n6lQlwr1EZBAE4EN6i0O4CmfwME0nb9NTVQgi6LsyGWodGpb0dN
k07BT3BZErCzkeVjKyPjwTcQfBEiROiOLDDk9NjdaRW1FDxY/PkSNHBp6luTVpED+hBNtgp3FT5X
PlUu1CI4WN9A7vJCApUdUQNk9ZOF5K70WvxmqVpffb+FOtWABK9en+gZXOHsmBa6y5tmxMpwsKY9
peMf9qm7U8s/7v+jZoenAcwHC++z8JRuh10Yhgu8RNT5Zj9Csz98Pj7sHvdpaXrAzv/0uH9Ibd/l
3SCcMhRbxPonWOl9fCfEWhpOhzetnY9rtcLo7SDYYNooTDsBSBr6GwApqlFPiSFZB2vhYFrr3sSN
qMc0vnu3ExAfzcoLn/oX+9WyYslxRPcD8w+1U7dgrrMyIx+1tIVtPAhvpnfGC2HaNoNGi2FA+O8d
74ysvn1t2RYGcWno7oiqyow4ceKV/rVZAEsTWiokvka1MFegVxt6IDNMRj7A1nDv0y1AZOnXJGCm
haed292Nzzs3B1VcfUFOoLXtxv3MuqsWqAOvfg8HbUyvG/B6zUCnCJljaWu3h4Zvv7uVcX3QhkYn
3mxf+0Y/VJkycHIG44FXVVyqdItDudIL7aLeNnZOdkDoVB4FGpYH1ahGjVqxw4KPcqX8YjkzuEj9
fQV36PGVx7CGQW2yElbuZ40GFzGocaFtYw/Bw2V316eNLbCnB6VB+BgtHRCPN3LY/USDEQ3EJzl6
gJ/S9dNFvLvkgMHIAaBR2HpHD+WeA7ooT/jDC+j13uIJiIu6IOdXMI/1fkmQYCFMH9kFjFVffISm
RigGSAV7QVAC91FxxKzvC8xAQ1VM4uxxkCjNFzSO8wiN9LxEqTDNULK4nUKm6YeybTqqdJxQCFkn
VkrmCaayfcK95IMOEq9lL1D2tnJJ+drw32ceW8OnfRRw5j9wHeV/b+yjFBVypmUC8t+u/AoSbTnt
XFMecPjNNNpckn597VqGotW6ThuhekBijpaU6A++AXvdym6RJikfTDF5RuCHx6VTuFQRvpYQ8deD
6Xb160wRLbno/Pvy6oIevna1Gv7K1+XoFPvXLPsQ62ahdSK8SjKaXHbQtZIUB71hbC0H31py0mGz
HEBZVjIGWGTGrOQqdDdzctfSUw5ObHJQyAopU+srJSnfIQFbUfJFHeYcK6XoKguJZ/+C7b0o3OwB
KYYjSNOSPmXr59PMhTR8jlCyBX5B5gybFmRxYppYeDIIThRxwt2EolFSHKBUetVxgtLYZAeSGJVG
gJoUZIQHY+VceEPgCGcgYD3HWxKsVqRdi42amY/DzWBHMoZNqSyu5oNrzAQjH8XAYbDyYfVK4cxH
MsMFcFIoWuIkZUhtp3yZ4QyPxcNwgFAiXCGcCUYk9UOtVNpNN5SY01Fl7oTCqO1gGfkNTcsOh9vy
xwOyJNjNOgypUknYMRzpP6jD3+DvG2WYYgRyfP0JA3g5qOeyfy9Gu4edfAMcWdKNQgySU3REu16H
ZzXaKTI0bBdgGteUtAYW7JHIF8AIafCwPwyUraqVWugJ4MIgK2/Byo8xgVGtcOEmBvRGsTqJzZEV
u7KuYEfB3AUcs+yNzmf0QynUE/EhyIXlkUTqYsJuNuJBrMhWTOk/YJvke/pHjFbCjU6vzheE3uEE
IWC4AxHhN5JwnlPVDaROscqNZfeQ8ipDwIAyjzEooRdNEClv+X6DGfaDMmAGAjIPXTNSVAzwY42l
lgv+xOYdyEQykg8vOCDRr9lKEh/huV14xqro3vBiWuiNdvHCSM/N78L21j17aeUErXvzan1QqCu5
s7yB1o94BNa+eAOaqkCoBUh3M1psRH2C6EXpoYfQFXiTfsJAVPDoCFKkKC1iWQ67VdCuUOxMiUfF
fNFbJWIVh8nqk0nFmU+DIfGutRn4wohadZNQytTq0RFO1ebREdJNhXKSFHucGejMEXlda1crlfhk
l2arpAaZveROfIOzK5wh+RdukfQMdkj+BkslwaMCBA7zVouEw6FVZOKldWYiqpVoAi6lakZEa9mM
mVU7j2oB4C8s7AVoDJm8KPLfJE5BcvIJRq0irJvko1mHuVb8kyJvGIFLESoZwUkmKCwBSKZLPUPs
Bc8hO8GzzO6wNDQjLEvNSk9j88MT3Tz1UiBQzFohUM1asnYObbhpe39vKvemcm8q96Zybyr3pvLf
N5UPry1xpfGSWTE/Dri2xcHc4rKsXk9/f97+8MOX588/PH95fYvCZbZmPne8tr2tu1TaPm6cQrRP
UQIX3OMac7dt7wrR6/MzuvH1racfKBErwVk6cbWSc6ePbzz/QD53OLb4m4yDNGjXxezDZRQji3F5
lzls89hbb/DBA/oWf/MGiZ1+R8/lAAwWndC42wOuqRjeMsCqWmaGRAWTUT/5/nyGDhM/y8EfYujs
aUt8PEo7MStZM0yc9FFBrCBZCzrK7awA+QKGKTji6eIvJPmiZyvQQ744vGKTETYiUNi7KKyCV2Jo
admmAho3SKz+nJ3ybmmKYhJ7WdxmVwxY3odggipKjleCo6wmQbCx0RvVGlVixpIi2SzD74/QpRY5
rxe4oi4oYdk2sedVPsSnY8U9KvLidA+pqYoqR6yxDrKI4ExjslxRGNDKtheKdKb8nZB3Qv7fCfnh
DNunBTYLbmOptwWWapO9wtJ8Y1F2+eRuwLQTH5vzUd1uASj2uzsbOreFoFBH+yUvbgVZHheX21nB
FO+2V+EMtOeTIssnGn/sTSWfFADxE+1eLxWOxVRoxPZdHLmiaCbvbZVrjmChosFJMSIW6pYJJzdl
v4heZTKFFM03kC6fqFyYxsM3lCIwDC0Oe2GWDl9Ji/g8FSAuDqPQDhK9Y5WsBKKCXT585QUJ3uGg
gbh8ReFXMkgv5X6+Y0A0siejnLqJihZxoJXFRKJ1T1aQdl6ISt990xOo+9z0JBh9t21Rpb4Esu+O
k4TaTN4Zp56dXEKVRcE+5BO5ULHQ8YW8e2wTp+aiAHFqbzFNFoW6YWV3mBtT0SAiJdnqSGpTnHI3
5MHrpCC/VN4ZKivNR2hwMGK4UxPWO2GsHRyhRY3JSauSIzS4mgPprV8Nh0FbnGXNlKu/kJbqYYpZ
F+ua+lPO66XNhwVV1GAmXJXr2tivKGBx/KWcwxh/7yH3HnLvIfcecu8h9x7y03sIrSE5C/MP+vNJ
FNnk76c8LBwoc0Cjgmk2LPtQQR1gUYis2OQiTB6KDcp7W+UsHxRX1HxSNDlh9yOZp2ozPeuWeRku
qlAgUcG53A04VBDnULH7G5z+zViOCqZpU0bkyqg0a0kuJ39O/aZXx8AU8XVwi6pEATRSdh2cDSqX
sVgMlpfmUziBnX4pV0eM6rAZpIDWBe8a4IWTzBGrISAJFkWWalQtSZUEUW6iWHkVZEXQWKNMfaEw
qvJIdOfznc+/ED5jecZ5BfoWf3/+G725s/ODr/w06TLASSyKejjg8kltHqJ4hmfPz3AwurFv9COm
h8B/CnEsFyfmLlPNemHPzjwNbb6syRRknZP2HCOVlzDlJUg+pWl1iHIaca5D73o+KdoyBh6XcZLb
cgIqdCw7KXyQO8SoIOdlMjzEpqkYkl3ZZ+whIGeT2GSXYLVn2GTrCpb0qC5pNYfILvD7zIiKdVLu
Uu18tu42jNvs3SSVkm8tTSDyGREVOjRmk3OcEfdqM2Izua3i+bHK4N8PuK4o/snRFgWbEPYaMdHW
HvEgrEnN9qYGEYW5aHWbOSeuEGdQxRkVaYkEzpy2o4y42A3bDesS1rAsDtsNy8KLuV4yz+YIi3I5
K2pb9l1VmBE5rXMzynlEk/O+Spz700VUwDgpWgQF5bGgpFXVYdXmHWU5sC6tegZK28YMrNabGXmt
UM4m7Uxz27SSlrx5gu00bemuvjNZ8/SkmgrvrlqXal4Uvg3aF171XD5avPMse53VDl1Cx1dFbYsX
VxRj8VtlaSD38n4v7/fyfi/v9/L+CyvvOMb/5untm1/9ruAo//TXt2/alvCnbZAPqSFYn5DST1j2
Ez+ieR9zOvXt6S9v37yjf+v29OPbN396+PbXjzs8/PHxeNi++gZ/f7X9/rE+fPdYHr7g32f8++Nj
Pljxj8c/P72ne7vei4Gk0/EPyAKnvUAupqsS3/KwPT59vGpwAUlnxDSpwWhb4W8f9gN3QSR2Rerp
AVduRnpwAanE1Hmz3vnbp7jzpO09fvVxe/uGkxG2Vhnatr0rlHufnxHar289RexL5VA3vBiVLz59
9SkvkR2OLf4mq2hjQ240jC+CsfP373Ijf+apN1/howdvpvM3Hb2jw7s4XKmuNhsHSuXO1XrTUs+t
OMqN98pmpIvf64jxPz5y2U7N4boTof7JfrW0yJbb4P2F+x9qN92BqZzjY8v2MoEkMIRs0ruQRRJm
BobbmyEw5N/Hth6WdFxdlTCBwBQXbpd0JPnTw5L8LsJIk3Iz2xk4i480JolldDyNgQ2mM3JwjIg2
hA7R0jsqFDIZe8/qjArMgK4RroFpJA+hQxmMJAobSgAFYaQU0kGtuDMSDEYQiRgHIzoahDFCEcUv
YVRhdD8So2QyioEDGfZEUJgGSLh6epcDPF3RYg3GbzkijlrQ9AhUUoGKBiNFOqnQEkPoDJpOJgKJ
b/RkHMBXXBfDgpHZ4hUcPeopznKpoGngNEQp+COsGFzVf/+VZz5L/1n6v4jS/7OL9bsOLUQTSaCl
UkKZmUrdZJZioLhkOZRCkVUohqOFZxQ5WiSSeJEUXfH7IXcxOPpABicPsKY1A/BITnfhMxxjwhYG
CVSM7pnm9FREMf2sWNaaAdbximUrnsCGwRZYsGGdFr6/jYECQo4OUfnqwI7BrZy/xhhVUzl/sKNj
tWsORhiewMZUR90MU0JhNBPLgCHPoZoMEXCk/0w0RW4eWUWih9IwBsSdSoJ8aH+OoL3s3ps4tD9J
3O4XsGsyHdBEZRONChJHDGxj7KAC36HqxHRfok5dY2STbThkhGA9NAZPjP4m7XSUctjKmiFFOvZc
RRe0yDVIDEbZb0Cx9AhCkGafR1czjKjdbjenODqBDhR1HYkr3V5NU9yTaY0zdzTlJLnYgVo8d6Gh
6ILleVHpASkDpaoZtuG1qcEwsppZeFlDNLSxB+pEYmQwEBaM5QjDJePZap+t9tlqn6322Wr/h622
L7V5eATtD77m+o84aGoHeVwxyxjpq3wPcr9Dlh7Brryv5x2zUalC8o43qXJJ5R2LsHIgGgNQI4gJ
pCn8OWBhV6Z694fCjueAFVQ49vloVOZs51H+nUEXMx+Y/kzZZhrkPNJIHPxhMHGu23mjWpKcN24c
QORcM6LENdsYKTgGCkQmQ1nSfCaGxAbMBhhUPEcGFowoWR23WDMKhkCymoOlUZ5uOdWJYVAMuQyw
1E6MUXs8+Z/1+KzH/5N6bO2x2Yz5ov//8fs+VuvIb+4z4V1czyAlOei0cfRJPmZZd5QBrvyf22iD
v1/6vwHZFMC7KoDISxzlO0pRUhFHHolc49EiaoO+2qTL5Od7dLiLdqiLRrvEASbtso5wmmVhoTxr
euT5MElmaiwFRQJG2xMHLPMi4hjiAGQyfhWBEJc0b51ZewOAJ2pGNugBMAsHU9EgBt7nsujTPscL
XhrLOgS+hY0Bernq9xPMypgwJ5phdqWWX9qVQBi0xvLWGnmN5b028joVmKZtSugdLVDltAAUXKd4
lxYG3cWeA3AMwH2ccyMMcBreZPSHHmBgaUZAk8E6thm/Nx0W9WSJ/IbJElkUiDrycyGk3KSqUgH2
4QT89AJTEeotBvT0iqIB0bzesn7tUcE2BocVS15ekEzLkgrFba1QeK9lkBVBasZu/aoISjMy6FD0
myqBokus6Qo6sHkfb5TNdB1JGjcuqRQeVVJt3AylgHle8h3g8SoPCh7AfK0mnWQg0yMGomFI7zts
62A6Xu1EP9MOo27YxJgz3Qx5XKiejf/Z+J+N/9n4n43/F9P42+r/27fPn379+6Ot/2/fff4El639
g8uRM3fq0OC+tXmwjU/9jbBdty1f3v7x+dPX/We6vP30+dNfXv74m9c9vvzptb5cvho/v7r84TW9
/O31ePln+/tt+/vTa6iD8a/Xv7590w/OdHDzpJtvf2IIfHSj8OR+1jaOebm8vv2wRFxCb/upvRQ3
AtywHUP1Za/NWEt/aokn/cXBex7haiZadcyD6cjfvel3Umzvq3gJvQf2YRlT/xGAb03MtYdYMcre
rw0qfLH6NIF/ZpPjVVrGe3T+v4S+9aJoNBsNUVP/Ker/2lpsgU/dwdhv4TsytsiMIZEwBJE6dpeA
6BjTBkXh8k1L8A8XZbC33T4Fvh6N/cdvh9ze5Paz3DueW4ZRC1Q+Cwr6nkfmph+5l7L2IxvMufch
y4DbPpCxuz4oOQJZjBP5jFhkR42Zz4SQ6DFutIflah0cM0G7VK6enhbOPqK5uy5OMUJdwaLcygK1
yBeuJrAYiawcMHayXm01juGknRKNE2PpJdq76+UUIxQ7WJhhBZvl2xCcH3HCKZ9w+VFO4a6jfMCd
TDO0jZNTbPCeV1qOgIRokR6wQC7y+1XnbqIkOqjWQfIJjKNjtmu/Agd2Mkz7cY6SwbuOKrl3c65F
Kt+Dyac7NKh+108dUeyHyifE067rTUBKkA5MJpQHZkK+Hy4Th8vUeP/pUB/cPapo2AaHO4tlHLfb
Nhu8G2olR0AccNPF+FARj1wi4FASna62pCL3jyoK9qYkjuxkfFBQZO6ul0qOYECxsMsZtUgnO6v6
88B0ucawwwrspQCfS7AdxDkFj00rLUcwzbTiU+Q72Ak1YRGd3YTq7xrjVfZtLV89/cGEInN33cpm
QjWUZkJNEBa1yGc7oQQjkQV3relk4d5RRcL1tOJGlLFxdpMM3vVTyRGQLVqkZmjxqSJf7Ue7qURs
QH0JGxPw4AlHU/ZgY/ii7QpULJMhFs5jmMyNne/DQawFCQh1UnyBLZGMg6dKpEWLNU5QEzYdcTZh
iYizkefgVEieIRbOzpI5cradfdNbLUnQS3TYieGgTJXE9cwqwmAV4BAW3lJ30O7KJj4VXIiVhdXC
v8NDudWCBJ26LENfIBkHTxXgupwqDivt0eJt5lEriz91wangQqwsrJ4GIT7krRZEIAb3AsY4Vclz
FU4VBxSXafG0mKLs9GGPqD6808DqfRCVox9VsZYkIJtNEj8i7LlTQYCxgkc6NmxxtPLbUJ4ATtjF
VrRX74MUHkqnFiQQoTjMZ8gizru3iJ9B7rMLkYa+pXOZn/I39VdPhofuqJYjEAc42CcYtoc1xmFu
tQN6WvFnt3Lb9n59aGawCY0ggUNg+zc/AKZKuNrsBM4uaxx2QDYBMyAbbftQU4g3LaweHY8NSCNI
QMBDPyGxA5J29qlxghrtgGwC1dTi4ToRr/VLC6u3Rn2sGrXguzl4Qj8hsc2IV/epcsKa7HxsP8x8
bD9cMxKFhYWzt+nB+cjnaOgeeQ2rc6dG4tyzSvLFAHY8NtqMx/lImAouwvDBeGRz950FNx7B4l7A
sOOR93yt4oBmMx4beeipIe+GKV4943Y/JWP3/dSCBMMOxwUOe8GLG46TMVcHeh7uYa4ag/qidqax
SZM8OHrqLzae8SmIn+3Xat0ZUgfwmpbxiAw3MdCZrEL7z1SxKE/bySb27NigZeM+4sIPw4mgWtD6
EGKAVcFFRmtYhcovP85M5dcjJ6did9Aq5baN1QJDBu+5K4KMnXasCX4BhU4mlbHSaHmLtO0GJWpv
eXsQb3kL0ioVbtpYrTFk8I63U1Cg88mEfgWFTmaVndM/VRzYgCGcDtOiMR3ecRydVNY2VutResxh
EZzoD3OfbkKZKrT0TJXgKqL92oNxmLaP6XDAPVmruDhrG6tFiAzec1gEJ/rowJ+Q0MGsQYvRVDlh
jVfr7mGrk1cprXCEWxZWi1BRzuIba+3t4YuTdjaN3SOxzkZOPytEXw9J9aZ3tW9Mb6Ntb03DhTjZ
9ubcFXv3ciuCEzwUBx48FNveeDeaKiew4MYm2KubfHsDF2H4aGzCY9cWHGY7NlcY7NjkvWiqeJRZ
tSS9gExHsxtzjQGekW6PIFpgHiji7CYur2wafL2BnlWynbhnrEV1JNqf7Mjl/UmrZLhp4+xvMSP3
I4eLL8riZu4Ki2trhUtgqrgFAbhtB9x0U7oK/QXpEaNAm29TiJYMWt4tGGzsznrBYikwhpG40G/y
DRDBagDez6nhYGbu1uym7JRBTGawGrHcsnB2VMzd8VTkJnCIDrjHQeeyBq62U8EDLdya2VXZRIOY
LNFqJLhl4YPt+U4BT8GJvEQH3QOhg1mjcN5Zo7hCqNyo2VnZQ4NIbNFq2PhqC6sNmczdXZB3cMir
LcgzDrC+0kasNQzStkFStyZf5xYaRGIPVsPE11hY7cdk7u56HAzysdkL7AUIOlTEsU9rDQtzv5qW
NJfPIAJHsAo13DCw2orjdPOjBixLcJIFfTMZaozlsUn2283U+2QUpov1VNbOIBJG4XCxDbaLndZh
snZ3G07BAQ/FAQ9leW6S3fbf7Fc7iy65Ec0v3P8w4b0L2+7WW6EX7MDxZMbB2mCDmXFg9v9jqVVv
qbu/YB0sLAMzo+qq0ilVqXTK6VAt0iCaEFioe4qcVBhc2q+48Cu3lNQYtU8GtQWhWxhSdLYwMKNo
P5p8OnKpmi1yz6WHFQt+qffytgw8BAPc4tAdrAm0gQWaRPcBA/2kIiMVFj5deZhDjfJJvYs12mKM
5k1lgd0YLRLmHS2SKYR6Vk7nKZ+CaEX8XLax9A7VixUk1p8o4eks9eZwtpgWaTuoJSWEbSvR02P4
DUEDwXUdzZcs8j4qWmpU5SIeA3tGEpnrWXPnGiyCvspFc0AipuL0ilmHm8tM7vpxNFRPDLkrCnrP
SZxhJKGOR8H6BmZjnTTBni90GGVDw0BU7DtGfFhY4N6uBoEYRoM8ffZ35JJaSMUThjeDXhNolk8b
o0XEbsAKQY0SbZMzIxkCPf+Vvk9+DZrJrMFyEeJZNg39LXUiLRkc+18AGBuKtJw1fg0RxomMh7EX
ji+M8pfKqaytV+ON4xDvqDDuKTCXYDBPOMa2ZDKGpBugMEpkHCycCDONRiGVsxWkcBEmunqOU2oC
ij0stxEaJr8wFGScGXziMPK4gVLZHBtZz2Ggq8eKlIoA4nBmlwlH0WHB8HODFOh9RvYv01Vtuqo9
JbJezSwyXbdDi8lWtdnCXVDjpPrXqJDJZyT6Inc4NkhlfSJsvZpNXsudUgQQOncrHDp3yPNvkAKR
z6gfRZwwX0zKC+vVcBJfi/Mw7QGnFd7lCgebAKuXGrrskMVn1OcWQVODVDYHS9ar0SS99DooRQBh
o5pgHE5ZAMu/AZrk65dELqMt8KSfFracQ3wtjzqJ0XTlFQD9+jWBfv0MRAMqi9LuuM523mH1T+4l
xNm8Zc1ZscdprkseTxWbZP2WNaYmeiHyuozfTFEWeyblsheSq8eoiumFSB7lLhMO0xzrPcyqmmNV
zbHakqz2DOt1c6yvNsdqm+NiW90LkSRfA8vHiHOE1VbcItpCNxhdqWw5hYRuniKSerD9YdEZCLgp
mTjzQKxB4ugHO+Lkh/5p0oNxy8/WV0GeFAmCXI59Uk8GSSPbDOLA2kMTCJJNNEyHQ2BB9VBklLRG
A49j5MLDHKiDlnQGGq4HXNxH4nZB4x4lPG3MJn7TkU5QAx5fQYOkgvXjaZUG7tLDHKxHXv6UVqkI
QEIw0Cckhw6WoKHJhBVK4ZwvRAGfa1k851hFpcEraX9Vwn0OeqGCu5os4D6naQjJ3Bp9Rem7XowC
4AChiDhCEoSiSkKELHxcle8I8oXqFbBd0Eh9WiAn/VG59JlQJpV8DhQKiAOFeuG4gs2t9HFZuo/p
FHqycAXymBbIST+YfFOk3JMTrmUGfSeDH3xUcs0erhIYejpuXxPU81RJZ8J8f+ivcMC+nnLinTIx
SNvDcyq4fmTn0JUGgXV4hZvgPJ0D09pMzuOUAi9NzPxHDpvV0UYXd8flSPNTEDXXo1purZwD/DO3
ZDLBx9vsuxyuf3QokPffbaIDua3M5qsGBL4eUjs6kO/an2rL6tYYaNuomxBbkEB3FY5zlBOHCdUj
DC7tr2r4MU5UY9Q+GdQWxK7j9Fhc1S1hwmXmMKEbcJxw/YWFPlrp4bIJPUZKelF3IQnc4jj04YRN
G1igCagEBBoHOSaiEDdDo9I4Oilwb1c8IeLY9MiKpCYACfrVj1ta7MsGyTILEqBFJloLBtXJUNNW
jHp0F/ZzpODsmRFJRYCRisGdLBB9NLk3WmkxIS3MbU8Lxf0yMg/WTlfWc6Cv8b5iAOdkAE8QDCku
WHdoYkFW5I0QYkUKXPC7ocTVHqvwMIdZN5HOu8KtODwy8poM8rqEziZ10xUwQU3AmpAVwW1hVgTX
lEkQXFMpcG+XpIhu/RP9E4rylhLLiZsiRdgbnLqi9DkzTZc3ksMaV5KDgEKXgnAdFV3wB6on9OSN
NDDpM1w/8TkqTlsEN6fbxzFlHDYwhrIls1bcfnH/HiMqGm9OGm8pC7ykX7Zs4lnklHks1SISWahF
JpAJ+SIL3NslkSV/jq/e+nUkTZ9UNTIxjcAU7MY+qYJkAxKkoAvscKZEDydLVBpEd+XhskSfaTsp
MvRUDPRkkejTgbpliwkqVR5GW1SoGeliUj15bb+u3OdAi8Gck8E8YQjapGD55XSLksmdZnawAxGk
YS6WQeovYnxkdZrSQYjM0GYAQVtAhGxhIOb+sMgA43iBOEa4OcJCk0LpYXVDK/L0NlHc3U/S++Tb
yLDjpqcg2pVoQ3TmZCTM6cXe8ePeHT882LJgAOZOz+/+uM1pvvdj/PHoPWO5kd5nrDHafhXaMo+h
1I+E5PHJb4MfRIeq3hmBQ20Njxz1K3jbPZUmYAAOhrvMMJwyCKNZkkIbRirH1KYwERMMbawLg8rC
eDUXMtTbinMmJpwEE13+GcauLQKQbTSYcCaRN7xIWRW01PVWcBVjfDVxSlM+e7xL3JaQxSNmEjee
iqyeuCzfN6ka3dL28nGDkJ4fNwkw2V11yPCW3cCCrpm5xWfVXqVmWluu2/tzOMVAzclAnQAEbVJs
HVmIMEFkNfpk1b2kcrICsL4ae14oQtxTYK5rjKRRt0dcSRPnqmYW0XtDMRaTYMmdK40jt+y56qkF
IiMCTCiS2pP0K1I1+i7UTbuu/XiBrMCrte7WtWPlTdr6GCynwHMiPV3uM0Ifj1brTMt9qtwn7xDs
CAVWxK1i1INpDAMWpSx6M+3EiDMgC64HU/TXdaDxL1PGevugPNHrIY1xKOCsH/XMxzC1PXGq6DZF
G9s6yecdEdFaOpjjRG/3jEqoAYYQJEFqgpiWmwZMj1cULIZRF2RwCKb4OQRBx3mgC4p7L1ce5jiP
DRnhbXvhbYHzNoHToVoctC9auM2Zs9FAI3wPdDawQwhwNm11UCFDQUiBE+rruj3zcZtRqQiFC+PA
rnM4b4wWEStvL7dQOakBRyRHxZr00Xg3H9VFSsnZ/dTDepigMHIsizGtdkX9aKvdwkyDA9D42gR7
eBMTbLOoauKNabQJKWAfc6zk8GGKZUVPSbKNs6z3RQNChhYWantZgxrz2kuqx7wmUGMeWtj1OrHs
7j5W1oNENYGeT69wsEXGEkaLbBrZgZw3FEkmMrwiHflWap/8+Pd///X15O/92EqkMYwECQl+P/ly
cnctKDQCDINKFn0MVYI+I5RENzCfcJUgO2kST+RLAezaBL3BMS4Q5IPqf5isBLRrWi2TQrkSRBXY
SgAmcBZKEMSecJiLdaXT7uloc9kepGAkrAn+/sPvWfztZ/FsGf1nXErfW3vx+PbSGrf351u9EuCG
7mw6syAQAjeyJwVn9s7gz4OqI+ELAZg0wR5WAto2lvNFWQkKrstqCalo67QS9IwIA7v0VHADUBNg
fZEgyWPg9TjJ9gfvBQkqabhzx72I9UgW3cffE/ibTWBfxwQhQfKCOhMUBCQSTeDdWqAwLNZRn6oU
SAM8xnnt6NxjWgsOOnhArQV0cmCxWIeiUuehaXGyXJBRCAEl61BVLASUHRdkdua1T/JolQDCCMUI
ikqoqgDK8MctO9qHZed3JxE7xuY7HFHax3hSoHr7C1DkWthTb/h1fXb9ML5DuR79bUoFWstJWvtP
D0jSVz+e0e4mbOeoWQZ9/emH28+a3QK6vulodQB/CACfl3j7Kxr0mj0MwD+9f/3yhz/7tsf7P79+
SSf8BqO68QyHrTbV98+etn33b+//+Prlr9/++P3Yv/3y/fj28f3HI377+T+//Pz9b+9/6Z4yeGrA
uqv2Jx7HgNljOz2dXr69fX//93LvAtNY3mqxe387OrLQPLbUgIPVlnWMrif/mPb807ukAG7PPdZU
9973Prug9BuRaoK6d/68yFLQyR5YfFgXUH3/D7/j+oT8Jn+bIEoYm+Xe37pg3O7uOxQjSGjxYV3M
Qfxqft3h+oVJ1aPPJvAOBaAx1nAuR5++9Jo9fJhxUbhrTehmXtSKAGQffkeDYyC8ho3ZomoN30tP
BudH+BwcCTAa36+lFrCPOby2F0cXynV4tBGC9aPeJFhX1ujRJJjPReuHDlFGG3oQMtowip6DI5NJ
sIyWHD4lUyoClMMZsC6s0bNJ1QcUN12psbdOGV7EEsJoIhYEC25Klfw9JlNqAhRnoHor0NlPnSFo
BVO7CdOL4aZNR5ts6SZbutLFHG6SpXuTS6EHOEzhJlu4tC+aZPU52zrNo2txaBnLByPJWAssuKtT
cviYSakJWExdEpYJPpoU26iyrdyCycWIy/8Yr5Is2VEgdpV/gnzFaLhT5/237TQxCrC9qjKOQcqQ
QaB0G0q3s0B4wdaYGTen3ZtpNpRuA+k2lK405oyO2u0o1T7OJaXXP45M/AOudzqVYo/DtJGEA5TZ
QZnxD/YlQiZPPEliFv9AqvEPpBoDq0G4mhoTOy34MDgXSFC8UhXKhJ5TAig1Rh4l8ws/l235BdYL
04kgTFdj5icFn/jZQILihahQJvScEmFr0gheSI5tBJ2eC55bYnnIwp5pdDq9YRpBpjGCTAWGR83h
CQefUMQJZZs+fqqJxcS8Mqo23aqW6z19kjaQgIBGBcmEnVOy36AUKn/Uf+Ojzj8BfcdC5mcKiCMg
QgI+jwTYf7ha46meDBabj4YRhkuKpscGA8WHO4BhHDnKMIxfTSmG8buajF53FWaKUq7JONckTSDh
iHnZpjkPv4VFjl2JxfGNKzG6FkhGGl/0ssLq9pFfDc/EEYzom6S4bNrYy3tQCRWZxievtNLHJWyz
VzeOEl/NygTau8/cpjmLvsaUeXBF3DkoMIMCC4zeVljdLIwCbwaVQYAZBIgopGtjo+5RFRRgGceQ
8iosjcjm1s+63ApQyj1NywQSDi85hFFAghX2G4R5OJYV9Vi9Hg/QwrFnWK0ebyZXQY4V5IgIbOwB
U57goTqPjx/iwbKJ7Gm9DI5bcXK1pxlqHIHwWkQQB2iz+U0HMXaeaBHnDlJtoJEOmrAVVlcII9Wb
QTZQ6tz1z+2lHQYNqC7HraT6p/oDoLNuONzPXtNXN4eaXw3OBBIIYFQWLZuz4fIy8NiK+HQ3JTby
JiHu8lfXhTczMmHfdcs/u4uy1d5BiqC88311mz+bd5MR6q7C6o5QX9kPG0g4Mvz2CMNJkY22vE+s
pSJO3KtPFyQj5l2F1ZWgvrEfNs7eSwwPRBHsXsqueofyPOqv/OSMQOJ316iuFrRw4AJlr8wI3VzO
fk9uRCOtZ4q/bjsgo69JuRyLTaEFTsmfIypRMgeJ38UMwQ0XKHvlT2JWorcGJXrQZKsUtCxgW5PS
K6QA0jI+hOS8QuJ3EWLbOnflVlJ8xdIGWl+lkGcUtUFGj5DRfUodQkzOLyR+FxsEN1yg7JVlMbO8
E21F0VbW6CG+CUTLbSXlgHiAeYzRJmcZEr8DxR6oA8lemZZUX83SBn6Nu1LQOxw2BRQrC5zSPkaw
ZBkSv0oRYjsu7BTLlZ5naSON3VLI7bNsKvEdN6wJZh/DTdZEJH4Feu0oBEle+Zh3e4+J+xqnpYh3
KCTlsjYST08UfLoII1X2FInfpQrBHRd2UpVSj0N0kdZ9GcigVekrKQG2qhlqGINNzmQkfufFyh5j
kb0yOvnVJF3gVx2ZYp5gcFfJiCDXGWi0cmXPkfidj03rzJXlKfHdLG2kdWcWsZer9JWUBFsV4ExO
sckpNqFiM+tiyp5ZpteKTajYhIqdgKShR03JqFiEGuIwvtcP9h0LFHEu/GcWwkeeKzxrhXkHiiQ/
ZXtiW+xA0pZ2oDCoXOL0bTLjbPC++oU0VKLMxCYyMzKSwoRso3nWCisHG+oraiaQkF8fnEVKOCbo
Yl+PCgHVZ+SPn6JYRebqiJFvNM83E5RSsvOsaZo467kNxiVica4N3x/+VyqoVDaKTLGAUAsItdwK
tbwUqsZZx21h/rU1brGv+B6EW8dwlWhF4VYQbgXh2gorE2uEezPQCrqtKFNpIwENmYBuD5Cp+ENm
Rg5SmByg1ONOqVLtaYYmUJy2BRniErVYVpBqGxNUWg2U2UCZ7QOPte1Ztc+rz695XTaUoTSRANiF
GuiyowzFAzItconCo/O421xh5U1jezUtE2jttEUa6hq6ZHhhnsbtcGeDmj/ixgvMhc2geT72Z4OW
ux+ajSMYXnraRgL8dqO4eCGAGNXwMbXhCIVJcGJ0+Ssfmt6o0cZZ62xhxjVsSegY4Avk6zn/Ntev
8VzXApmhej1TfBmqkWeTv3JpVKz9u5DfmDQKrM1ZRWkDKLgrh5ch3R3KvzbKDY4pj7fi5WDS1Fsn
nUDEmX/UNlfYWtXfSK5xbodtAq231lkJDh2en3aBL5h/B/2kw/U7Dj8e/sb3Pfz4+eRuHGdow4X6
b+nGpdAP3+2gNfKkRhj8nWMBo7qEwJdFTphw/o1tqvwWqMflA4uJyNdz4BLuyeavuFKxs//9hmsj
LdciO78sTK05JQwNaIqHSj+GUg1DQ8X8fKm6FLohrGvMdKXgRffm4LSBBCVmDx2hSGdOEWxwabLo
e3SE6T5TzE0s++HStWBdY3XTKvXdfG0kYUkR4OdNa06hS42mTGizo5tQygmknFkwU/7q6mWlfDPb
hEpOqOQJhgvPKIUJJbl3JVr4t2Si48JgM9q2wupakt5RtYEEBDRZUJPSWVN6hJTuwZOjV7qVf1Cm
W3FrqLw1rGqsbidZ+d6pWBox+soK1GtSqOvOnHJAPCAlp69sD94JmO3BAplSVjVWV5ZUX43XBhIU
2GD3UDSlV0jp/gdqHy/mxvsA822sMs3ouHCjZqn3OF0bae5Uir191n05vqMaEClbTGF7Lni2usAp
ETY5V2Plli3dW7vs2bJ/Lsa0pw16TomwI89gI/iLc8FvyjH63TCmbf5MNr7clF0gwfCbsi5MnQ9x
+179uiDQwWGwS1WyssApGTZIV2Plj9+dt9pI0acK6L3D0M6ckr38Z6yFp818MxiMcwHUXFAgtsbM
NzuDcTPgDP7iXEiIfgeFUwqqucBmHitszueC35zPBb8jngt9X2MmXF9uzi7w6zoz+gUUvznHA47r
LVi98lJbvfJSF7lNUgnzrBW2dH9XVGK7vvOauO+6K3VpjtkW1fFpjtYxxKG0jiEfk9DjpsDMSqo1
+UrXtEwgwYAmCKLZ6DYELK/b2LGUVft4Um3scZLQd9kzJS71MCcN+64aSg9638cOugZEM02/P1Z7
14LV3rWT2THbBa2xVd+18b352K7Ar+ucGzTq/tuyEYSNF8Y0lR6JQenR+JUNidAutD07qdefDgsb
aXRooSZcaC6BpKgBNGllN5Sh5EgayqW7J5u/U+Pz3Ezc1zWdYHIEKVIjOvAeE/AT43fXU5SzgH4U
XZDsm2GdRG6/MBtoZhV/m7qd1dxVMto41jRlAnr9V3vgnSTEa96Bd5Lz+Tpuw0/k1i3ZBS0xm3Ku
d14G+++339KVMpW2jHQ9xXVXi5Nw52wSzufqYdJ3e7k/+rIv4xTNmZgGVf8dm2etsNpiqFx++AZN
oN1hLsvt+2S3wdgAAtb9maXcRKGxOckKFxKCPNsKW80ObjdfoYkzirU4Ey5QWy9YDRCc3R8sSrUN
w69Ux1YgzLqn3dqeppR6GqEJtLvNAmV2m40GdPuU/rxJOZ+9STkXnD84nzs87090rfZgUmwgwYAm
CMIe8Sl4kzJhDGBazgVPMngPoQmLAjPL8Mq3mLDvbU967xhE8MjnQm6OQmT3Khm97irMFKTc06BM
IOFwJnkBw5nmlLxpnmAmHh0TTShIWaCMDMO3FWaiySryZlgJBJlAgdKF3iOKP2+8WODiTVjS4kZY
tHZh70603pPxcpHm2xK/oUh0wfkV/rxsQPcZAZwYaV3ZBnBimjEtLOmGd2bMxn1d3wkpR3giEe4D
rHdlEtmmp+oUbBdu7gNa8HFwNtJ+axZtqmv4vbrPzUb4GwIP26vUCUMsG8/dLjQO3+kz5ndbv1hH
0qc4xxWM5hICW8ujbnDy1J04nTKn2EXyXpYPhtrGfV3To96j0BT/m3h6PHYvWacRG9xxoeUNP5Hg
4xRtpBWrgTwDaf5XIbHalDVUsWDcViwYd2HbxSXM842T1nIPNswGWrbqqwRHj9DYk7UB3lqfEijO
Wp+yLtWR/fPW+sw4qn8ue2ut5fK/393l5gCROPN9WguZMwCvjmqEt80SX5/P19vfJ7UDlXDXSLxL
/GXnE+77kLKPk374FVh0ynz6cacMF4PQB6Pyo/0dC5mfKSCOgFAhY1qoizND6h33p5+NIxzXnaaw
YG6AUEr8s/H0RMHn1aJmy/O8Q1WL+rdQKqR4oq7G6rYnaMLv+7i57lWPm+53Ba+dtvNRXQrdjIq5
vnmwdNAIX1Z6MScRdQ3+5FmW2B6SNNgXJk7A00dYzFYwIXE/EB+SNgOgBpAxnVrFnElePZqxKrE7
LR9lbOO+rm9sT0AO4+o03vOknVh50mZezDGTKqR0XGh7GWvBx7naSHuQFDzQFq0P7/FsCqBNPOoq
myUIOcHXwpvcusZ2O32ebUIhJ/hwdWHqzCkZpbwDqzY+4fVLFpInrAu2xs358XQjSXj9Snjdkghd
oM79f/arpEWu5AjfBfoPdZQG+jn35SqwDXN09834YBtrYFBhEBj9fUfGlpFZr1pgGFkjioaS4nu5
REZ8semD/dq0p20iC1la4Ea9Qkh0KAKfFkBydaZDLeBOt6TBLz50bUP3Q7dsnhYbUY09K7Giyrxo
1817M4ZhaXNUR9ShACzugx1tB5ZJbiuxel7/SulZVrIq64ypqogM/dCywW8z2NR1PUE7P9fFzsx4
AIJp9EQnI99vcudh6fWX2oWoRds6VNVCGiG5Vn1Uy/a9LJ0TnFiWdzYZGuSdjWq0PAzkusnl/kP1
tK9083YhqbEp6cOp1mqWtvaD5G8/eqHr8uxcrJ3Q+Nb/FihmwzlV/WiBxIGnQ9lysaXqCMM7iqya
e/F4uKvonL94h7cjBwCWl35137L99qF6Vnq97TXr+JXLhCE6TPcss9t81FxQV14H6jYjrQ+cwOVb
WDJVONom897b98lBNIOU+360C1kF12wiPtGCbjU7eth29GVLCBSt6soQiCzqSgC8HS9DEDu32xNu
q4Ee97o37TpWYx23phoTqGXd0fYIRo+XwRPbQSDAmh6tt4v9/fzLWxwSwCUVrJWSTA0McDADAO+o
ZPEVEBmEKGMp/A+UOwGCsi2O55wCTeSSTuWiQA5WRwYcDglmi3PHLrtm79yB0vvICFNvCySUuB7L
MHUCdDUchq0FwqLEBILIsdhnLN4B4B8/PVz2O3MZBv/4o3Brw8aVCtfVAJ4212FgI5XhBj+uZCCX
DUi4W5vAfAvEYLcA4No54NnwadinUpUxgNPPvdxIXhfTcQBU1SCcyiXZV54B0oXXY5d7sHeyEVml
xcYaNA/Df3PDDyDgC8XiJImJAPDlHEjL+WdAWUx2Kyc1YQ3nQNQt5VSeXklNqcGSMTsuN1YWWToV
ug+AHDYgbY7cZWlL1OphtbrsYLOdyDlYPxhPq2Nebw4y9deYJrHLqjRINH19kUZDUmqhZnMC9gyN
xt/g4LFlyHAS0a1QU1QPbYEu42+8zDapnbotPCaNIIbGDRw0GrcPP31lwdbZsYp9fL6aRyDAKmLv
1+VJxQrNroWjP7y8ffOHP0U4/uXj2zcFtS+XkNpBzV6EDS/X4T3n4uXln2/f/PXdh/fevfvP+yf/
7uPHv3+Cf/O7f7//28vP46TKJwGxx1HwTyiVjFiG+fEsPOfd5f3Lr+eXYwEvrR8p7Le/G+NXhwMP
73j/yZUVI2icAKa4ufKPL+PEnvrF/g6fRTeOvoSWR3xcCYAjQivk4RgSLTBya7Lh034Cc/E3ONbM
BTgDfAFyxNGbwKJaRp4ZM8DlCczVJ9FeX7EwLUYk1lhKKs+tpNHonVAkLg0ZbD6ArgvC2MDBMWT0
TeWuJXqcMQZADdwAxiNr4yYxjrES5dZEzuPSzvVtmAXt5LhpVDtJIoswt4wtLXDuHUBAmcU69B1y
V2DIkbV2mDWGnPl7oSvj0UTGG9MIYQZITiI6kgsDeTwK5FpERg2zSDGgo30QwBEV5AFYfwZA5SZC
8vZlA8KyJVRhDx8KQJ13jmQerEoADH5MnQEo5k0g9mLfPFpWYxMQc7FGA6AZo0ZHGqvRAcjWK9GR
kdVr0ZMbgkiDa02KTYyBLnRyYQwH8YI3RLywdr0QR4MBqFwXZsF4O0wA3CsKkMzEiuSGSdZIjpp0
juRYDQCQyxIhNsQkVTzC7hF2j7D7lmH3TEFSwxp1Qy5ZHkZht8jDFCWz6UGOtKBr2A3LlSK+4rAr
5dAwLLSgKBBoQdO4HHqWqmHX6Kl+BklBMWsMYegHsQ1ztiaJ/RsS39Ich0wTFn2h6Aw7uaLaoLyJ
2kqMMWGN98+wpyfNvNDo+pk3OoWM1+TkKGqcWN5R0DjNb56s1DVFeoxtAKK6AlnY1DdxSZC3GZRT
bNMFyhbJ2w8GPRj0PzMIU1ClS5k+xTTqnwgotg0oUtUjX5GlqjeRNw0zkgOAzDsSesaU+USJUpMx
URbsEvUZbKimjwazTnpyD7CwEeSqCxx5hsvhGD1s0fc49Brne7cQhR2pJb5T9ZolvlN9S/Ii4AKS
Ly/MmNTlJiSLn4VcOnaFIlsmUIjt7EkA6IpDa356vQc4KfJc1fmdULWjLetQdpGvexGuWqPb0ntB
UQ3kR9YRAGzwlL4RJamnIW0Ft1P57Hv9lOPW+jlkT9wMugC/kw+V15oqH0x/MP1HZzqkdCwzXy7G
n1maA0dVTm0nJSgrIR37Z6GPFlHvj4UPICc7/YBcaNoJOsI1a3lhqFheKBx1KKSI0CrKcygAM2Ro
gpOISuSaGXO5WF8B0JYqTEE5Q4zCWGcHkHk0kCLMiaCb4aSlc0DlXk7lqgxDP2jlFwI6HSacTLoq
c+jPESzSCCVTYF/7ESD92rDwUBfHMo6bZbKVOIpCSxk0dQws0lKxrSVU5yBZhA6cHgCIMz2AxC2b
RGqWbCCxnI+yyanZhBKyMHhtsvIx2d96u9jfz7/M1EsGvFpeSHJlXkyiZKLqDeC0U85kIEOl0E7l
ogAdkLViMPcmUBZiTCAu9LR0ZaKsVaqL2305kaQdVGrfAHeZvDOd5aSZtK4dazmRUtt0vQGKfayJ
RQXaYp8zoC82vgHAYm7zSti8tsvTJ+z26TW3+5UBzUFrzlG5a9ZqJ7JNWuUO4E2D8+D4g+M/LseN
na+LH+t2ILN/r5lYHBKWhfn7lz9TVfHSYl6NPKttk5aQzxZAGmuovj1MeVx1GX94vC/UAZaxh1Uf
bVfJYkxoCZFSyI0rAYN0uuK+7nJWOWSwoY6JAKyRdFbN2sXxlr5v6fsW7Vl5S8UJxGwhwGwBE21b
kIp2S5b+QbZIQ7FaDbpibGudcXhS4NMEStfmr8g7pFGnM24APQPz5je5SR832hF3+Rn+9+uFWAue
L3UQwA9vP2FP/flfb998+On17690OxjupY2Migo8ufGAeej974uecns7xjpcFm51u/0qlIdP7eJH
4/kUR0ip1iHVi/0dl3kwiiejBMwS49WB6BYwKwxAWkfk2QqMvFoqSZEPIClhNoOQmH1p3gG7ngZG
kajVNlf1o1kZEg0rF9LpApBzuXd6w9A3qlBqWQAfbEBDeuplA/gMmXizJIUJbGeE/Yyw6xFkiwCr
hXHCMtLmH+tBCbSHW380t2Iw99Qv9tdmOEwJXzDR1SNIFfJo+6eyZpNXFtxNdSZpuGqmyesCcFsE
QKdpkVsGN1KXmSYbza86fwJQaP5kCsC8iV1PFgkb06QdiqPxNGqT46RPyLqiJdM4eI8aBO3cgjQt
UmkC3TG7oEiPmL1dQiLPjpI6r9ptawelPK/9ZZVGjfuoqipy4a6H1jqshsV00E37GQawhS5iJnUl
c4xkKI5Fv3O1vAFmj9LLOdCa1eIGqE4kbKk2SYgMQDmVQ1oefQLE1UwWwDbPGbMg4HWw4S1+N3XZ
t1gAvVNM84/zQ52teyb3pWWEA4fPqa8QA7SvTrSg6gJHI4kYI24jj4/UEOu8EGQik4cIjcVajkga
DqU9iU2/j4fPMHAo8BNcOyisisoj0QJQt0Bdo5jVn2EeNe6bjWssRo908UgXj3TxSBdfTxfYfMBi
amOsY6+TCmX3K667TrIqve/2TONi8jdvxElvDFESuuE4kY3rvLjK60vQjkbA000O/GYXrqdfT3Y/
2wM4I9dgj0PJSwSzI/2RFi9jB2t5oLlQ8rOTfAsZOQebHF2nbNe1BlDOBqBqivZL+qQcDnJUINGO
Se4y86un7NtEyWmEG0CMfBOhCmiE9rDKawrXiJ4RPAyzAHhnXyUN8HSE5UWaAeJSZKZR4rFYEeTU
bEKIVPicpjoFJENElIryzpFrpQAoUJWJPWxAs2QBuZwClqskmNB4EPFBxP8fEZ/HfOsvjqoD+4N0
vU4XGuUVSGtdPQGisqilcyBYFpzIcQbL96naM/kntEWzMNhr72WHWaBtqpc7gLY34Vy2JvoOFHnW
QyEiwJRXK3elaziVW7JGPgPqotUZ0OzDVBYKfW96MX84D4teYUvM7MczoCXrhjOgqqNKOgfmllpu
bPadKve8XCRtsAJls/4uR1XVpXMgte0xqVmjfPOLn6lycD3+L/vV0hvHjYTvAvQf+paeBSSTRTbJ
OewhTuIFjCAI7LkZPijWOLAhS4Ykb/7+VrGq+GiOZAdwEC8yMDyaqulmvb76qqh23WpAA1+9Rrme
GtZmwtqRtJp3B+5dq3x8e3697M6whQ/FrIWVH+BXWQe/qkt9xTTrg5pYOW07Vv57vRDkyKKmTrj1
5uYOSNVaSgcV7cazlrok/H32Sz4SpSzbXji9UVZjTBDuYrgE0YeVTYi3Olozxd3UraFFhoK/bTik
UCO0SOZteFDUXVdWzcbINhw0qsuuOrmWfZv4//c4HlpRg3CNLHV2danoFLL1hP4JVawWzK93cEaW
36ap/Xzxn4rg5ChVsoyYorhqFCCER2dNRtLA3/gkr8s+pv8DK/qrYFWo31yg5gJRFKmreoK2YGup
NJjj+0RzQ/LpsKKyteNXygPgD8q6D7gsbbtZMCpK8mDJ42BUtEmpaSsYOObya+TyYdg7T15ACJQt
SrALeZCxIp8VsrtILzwo3MI7dhTrePbT3enJk2cOOWH39vQk5FbADGyXnIgF6QiP3H0gJ4xZpt2b
05NX8w+bON9s7Hz78eb24n7/68bCfPtuc2bdfH2/v9283j2nU6OcigHSsfjHeZPDxXMxunxsPnKe
Nrv3hx3Z0o7v47nz1Q/HL9kt7r4eE4XkIu8fMIlBGz4CRos/7VpCrEzgTaIkeuTNTCneJqqpx3Ix
Er3J25F3cnnzOAgx1y4tkltvFqqGdywR1gElxCj/2pwvHaNHLIEHTJEXahO2sZYQAzw5vIuEm3wd
4LdDUOmKJUjhvCwxwVHTBczKwtiImX+XbdTmCEAHBmPZQxcinbUsW7HvlkSPBlPuFfgEAjJg4NLP
nRGJkrCPmQzB0jkfSJFjEMVVp5CpuJDjVYbgMUOBWiT7rjJweAB5cgzy1tQlzpxHv53aT6q/Xww5
HCFJVopCFyBSYFVJwUXwhE8St0XGrMUCC5TRNsneq8LwAzzWvE+UP1IU2dMDSgCkQOOkAHki0hJG
igVUAfxKlFcCeeVABUfvKy96v7BF5UFSACu8WPBsQXmOFIYVScJwHBeUwIEPdRo48JlFzt6SrIkw
2UencEbZdAqX2AltGRf1AZED+U+ytoBTk6rAgNoXjLpYZHleSoFl9K0HiIOQVgpxQYKAqD6wRcjc
28k2tGmCRfMmiQRPPzWpRoULbTHA8ZmlXOC43KWgAE25UXDQggHhny0UuFA/pBZQYBVhAjkwbFIx
iXIuXgEtKmxoYQ3cF5UOuQ9qY9jMG7VxUCY3a2epIl8tREGpgqhG9cyoyZVeDCW57BUVAVq/UeFT
GxgE5UUJHUKbGSxSnztULF12YSm5y7mHpaSOqwW+pIrrCb6AiCsOedVvMIGKDjTgdZQIysAV0DAO
yRa0SAUn2WUkg9O4BergFEPSC43C6gmSGW6eRnZ6hBRM+q9RRPVKX8n3mlbBLd1Y3eoZrtCIWFGi
YSqq2RKyqvkUOqsZZ/arJRF6rDUTAq1VFYqtdRdSrjgR2q5IEmKvWBPmr2iU0aBo1ckRtWUWQWvB
d50+xq8UdX4eZ9RxRh1n1HFGHWfUcUZ9izPq5WMjqn1rOLe37KUXW1eHYFbhDgkZUjYkdUj7ui48
mMArX9dKpgdKXcDgCzpM2zoylmrrDHgaEDdickDtgOsB+UNvrJtn6K6h/9Ydum7hocUHDhhYYuCR
NdEUJvJlGK24Cg9LTUVk9NSSDfQ38OPAoAc4tqXggaEPcPjA8v0cWA+KQ5NkmDWiWPppZNSqnmGa
eUVG6E83AunB1k+U61SlSGwqyeNYbSqzgnODCmiTZ2OZcJxeVMQ2/yh3q4GNza6QWAFdiW1sEWAD
PdVABBWhAxEqlg5mqIACTAKiDSVORioqJLsMZbuUvYyxjopuMasydwvKkhfpr06R/V7KsrjkLm4U
3KPNK9zWjSLpK6llhiLzglqjkA22xincUjMhbFSTJ3xV0yuMJtkXvqvFEUas5WPKLOUVSq3lF9Kt
ABFaLggS3q4QE2avIBTurzCV6VBwvBRcpzJPcgOa5lKUWaE0y5+7XB0n13FyHSfXcXIdJ9dxcn1r
kwuvXE93pydPnrnJTru3pydhMvgvTH5xOQCsp0UjOxxoJv90+zt+OzfGTbs3pydn9BXf/OP05NX8
/caa+fLydn93N73YLPN+c2bnu5sr/LPMn0i4f5e/31xPP+LvF1l18dvF3X7zevec3IjiBvpPxvDP
gh5Q1EjcmEn2gyybbHSeNrv3B/2PMsMQFF78R1d9fvfV/OvGomsbP+8/Xd78sgnku513j7hhEpWW
yLD68LB1zB5Xxpm18ZwykJTFiMFhos/N9GHj4nzx8eP+crq/mX7ODpFn03dP6et3j6coozMj5ctT
tAgnIXUNKeq8TIm8dI97+QN+fsbJjF7szYd8/Amh6EL2KmD98holcp10GCVU8SU5nXyc2k/GKLbu
HxO6gK2KHRVito8nWmyCRBaiNJZNYa1w1FnyytX6DNn4/pKDczzRb6f2M8czPcdEvs8BRT0Ey+by
PD5jar/dYz//67OPZCMhp6t+khGLRiwbSVwGv+TIUiRKCUhaWwmEFV1kuWwlsnqA5uvrHvkgdWG/
Y/MFnF2l8z/HXD/fvLlgmsrE9Av+f0lkNuXPzGO3/93fPoxuuwWiSzT65f1nsSDoYKDlNNX+O+De
m5vr+wumzuu7iR29IaeK19cX2Jhh3mN5DxPuw66D2WYIQobml3uPUxm9DjRk4VHvn1IOszdv3140
zk//3sR5stiotKnhmHksvfmKRMZwRj7CHg/0DgGLuACwL3ASughE5h9YgROdFIzConA8p0nG8Eh2
osg97aKX9YMUwWcFbxukYLn8bkOWgyhokSE5JZUXemBRCUiQ1QMQzclnhQuqyDEs5ypnIYp7jr1Z
SkCOzQe5bABuRyFlBahsWNYI895PikWOyPsxKUJShfFZwbLLq0ojJ/Y5yC5DipzFqElzkd3UZgfa
E3s5S5JSHB7Z56rIBWuft+xSVRj2qZiE7copVEDrNST2qchRo5I8QGjSxhenJq+oMF3m+bbW1Cbf
72rh+ELYVJbvlE3t+d6qyMArRQwtcFABqUEayqZDIl5TOqiC5TS68/K7Z3BrhJZA0KC9KooMbbsU
2afueSghqKIzaOWOSS7nLBqFlgZpikuSA1NckiyZc2jTGLZN3iHLybd1QEVoC4WyT20pw7YUgh+3
0OIgpOJ04gNaRWBF6LCGCt+CscpWX1C0ZlS2iqhPQOkp6I5IvQnpyeqDdG31Uvq6UXDnh23LCzVu
YY6aFuGWmjjvm7QKL9W8C3PVwgi1aeGU90plhRhL6ZU5CzhwTSHsLIWahbuVKotC/WvpXtaQ4ww4
zoDjDDjOgOMM+GfOgJePj4D61vrczuzg1drtA3F1cQ95GTPX5nXI+lCXoXJ9YYe6D8hYY2cNrgF8
AzoH/A4IX7XAukXGHhq6LHIfV0XIQwAVSoh93w5tPTT+mhnWzDFQy8g9K3Ia6GsguIEC1ww5EOia
YaGBtMihOyssJSNFEXxrHhXdSEDZliNI9mVK8lBBRWoDQrkPOfjzjp+DKx5KFl2fZVfKIlVwJWQp
nKtFhabm+XQoAQkIQPtTYQLnPY6gTEVBGpSQeRHoFIkVpudvWxYaXjc6RWBF3xBFjvp7vxJ1ipVR
3qqqW9qmrSInqoSmra6xo9zlRomhZE+po+RXycV13OMKs/i2UEpcrtlNu1Iz81UoCDWioo6E1GBH
uLWCS5brgj7Zvis8hawr4lVR1vnsYSge/slrwXEmHGfCcSYcZ8JxJvxzZgJeE57uTk+ePHOTnXZv
T0/CZPBfmKxz+mTAcHc4Kkz+6fZ3/HZujJt2b05PzugrvvnH6cmr+fuNNfPl5e3+7m56sVnm/ebM
znc3V/hnmT+RcP8uf7+5nn7E3y+y6uK3i7v95vXuObkRxQ3MNxnDP2DREWUAdoMMm2xznja79wfd
XwKB4n+0V8ty28oV/BVUNgIXYjBvIFV3YdlJKimXyhWpsrl3Q0uQ5UQidflw4r9P95kBCb5GQCwv
DBMjzJme8+jTRyrfJ/hAamXvr+WniQKyiS3bzf3ieuIJXZW351Gouu6IArm0g3EegJE0MQ5prQ8B
iNd08lrTICmmxk6r4nliQjl7eWnvi/Wi+CigiK64kJ8XeS8xdZzAHO6mDiXq9MhNeyhx/9dRXg1F
qZh+Z1D++ZYgaqiO/pNpR7JjfaHua9EuWlqZQZmmenFWotRbiPQtO54OLHSS6M2t3vACwTZF/yl1
U/wdjvhXcbAFhA9iudQVnbNsUZKHsI6+kCO8eGf35BEKR6h4hBOiNNhUx4s50ojRpmO/+L53LW7Y
XmvPQOetN7d6loI6eVGZaTWUgj4u7maRb4RhrvHvhqxUyFMIafmtXWZSFMqEBFppwhtcSLoKvJVu
/LTqFdIJhHeL+XoWaXC+KiLWBXFtgc9nqDBftgj0afLMoK+luevGsUGMQG/ZAHUN8VhlaeA96nwx
qcrly2I5W7fCo0visuV83S6LXyZ1WaiG8g29uJo2GayNaAZCRjccjlWFqdwUaWSzWIWY1hNdPgm+
Gfx+hM/lMqGmWsBBOaayyonfAOU5vQWX1ISBCnK6t7Dtx8Iw/L7yUQZtNbmT1m6g4mqxaJpaZFBc
6MjlFDs6JXiNrdNWhxKLZBvVi0typrcQ9VLc8XRoIlX8z7A7gCG5Z2tDS9+4xJLZMWT+iwEMSZz0
vuF9nuNFqOVNp/C6hb2bccfuZn0TncPe3uxZjrQ+xN6Ee9eHHHm5oyD+cqkurt/doiA0GPL65nz6
20ZUKi1vyXdAeVoXkwEXsDpLhFdkZCG2h4dZjwd/mYSy2IoiVZ2H6KpG9DSdNYKrLToQXAbjNq95
SHaPILvIb3eQi7Mvi0ghWzmUIRAHfrFyjslSiEOUWfNOYv7cW2jSpGPR/1k/24WzJGAVhrnCNzLP
kmC0SC3fBLIITSH3mv0FRZJKW54OTKSU/glmB1AAt5jtHq1FAymZJDsOeOWTASRAoPjah8Ca5N0w
xSEbfF11yNPC3t24ZXe3PRudz36G4fNEEDyNeBTOGxOBq3SMdTOOCDCrSkbo14hgXxEtW1E/QgXr
9kfEkGOFC4Bx7ACXI0huCDu8JoW2NJHRQax2FDdPPM8Tp5jfIC8g9/LOfUeWXU9UGX2XRFAYymCB
MecxdowLvQh3Dyntj3x4hlbpLWQ5IPlXIaHD07bre6vHpwbHI+IeFaFFQqX3Okz7TNS9qjpe0lfs
d89coK5I70+7d8VmIyrO8i+7BQXRBkwOrTLSY7dgIOtkR2DHOXyFVnE67vfcyH6hdNwvGjctPO0W
qmRBgSFc752iGH7HTYwY6N49YaS/I4LHC0HJG5BBRbiq5n/c7z1zMi1sIdtGOu3z7r3qpjy86+P3
KHSyDasRzM5oOpMsCZ5pvBRvdL/TVpy3e5cBMu14OjTRse9PsDukZe32gI1j275U4t1ty8p/MkS3
aqE0p0yU4zIyONVNGd3C3s34/fYiPQOdZn1bk5k2BV2IPEHqV4dd6gyD/RXk+p+JBneR978XHyau
vMa/GzLbb/G/9m6zbO9/m+RY1lFb82QzYtq0jjQpie/siC72ZQv6+w+1MNswAjx+TOsFMwGsrcGk
dbaHfXzHrnXFR3Ehvy+K5G8Pf1dwN4lZYRYAF2kIZ5UDK+Muj7Wj0FaRisJeLzuL9hrto7i4Ogu2
6KHVObRCkSGMbG3RtQHFP8S1ESw73h8OsB741bzu10AuyA0SCltjKVkLqyjGJrU0GyzzyOk61S+N
4R78wtYd2WGHFhnPd695GimgitoULYH8qe00adXeEYlFYs27A59pdIW6CPg+KH1KmYatMm2S827W
og1aPFX5gie8mMk8gz4F2DzivIeOg6k9rxAMmlT1f42qhZR4LOPVY7sq1oti1c7vi9v3IKhP3PXH
v33K4LYiIYjAjSAl7R1JLGiPDpRNwvsZ5B5AvaJVP3/PYDSUZHLYKIgN8ysgPV6pk44UbfkNSjBh
+lLcL0CaoZylhUiiARmRASozKY8clwSGSaCgZ47Y51WRP91VOb+cTjT6wHMOYx3dotnuj9Trce1Y
ZSlKPIepJhbPiJLJ0J810q99nNKG81+lqIWhF5teWMMurK5HfxaOaWJjseTqCXu4wTTiANOUKJ5G
FjLZxykynlePaSmVtBSPuqpy41HJYuXI+fumXa2Lh8UyGTwFJEgg4LZ6TL+I/kLxVL1JyO2AmJ6/
NPwVpF0EuOtl85l1YaQmDOYkVxY5MkmugqAcFVCmYuFRNKo6TP9ydn+P8lyddwr0IEdXJW1lSDpj
bqHG9vW0MqPTOdcjlcx4zod9JK/dHu2/5ja1lygnaOqGdd6CCTivbsgILZSol9KXvyGL1pvlfJWT
oEqaMLrOqBQKIlkdZsp+Dp1oUyljuo50h9JixqALFSmSxeIhj49DpTPjMghTJ4qTeqqfQq9wwns8
L6YTogxgWFNmWNPpisxOHZQL7mGyGeUJzKPJdsJjRLLZHIvLGETDYzqNodQDHuzu6w2dWk2Sh5Zz
joaWvZhchvId3ZQXEI0Wk+5kAR5hqAKTyWvEbJdMqt4GC9UZffJ1zmB9XU/gjPSccUV+tvy1miio
7X9SAn3i4zqHU+qex4YRqUWPBXJaNW2O2GmvPG8383kbZUQhGjv26PVj3ndowjQeRlAGMWG3B+E0
dmAU34MzslHU4h2YHCYKMC+Adm0F0najE9tlWkigIKbdagxBmcDssxVuYbMElZxDGQD1LM7xSHEQ
lPwqIPEwHb1kONTWTuavagxBgTcQaIPeY3pZ5Hf4bI+gDPK4FoKqMbPNcliCY3aa2NNGwAkcqUwN
Wj9yV4lV56fsq+e7Ls71sl8PyRblLV1mqFzG99z6/P1VrRl3Gh5TQAr3x/cGQqVT3Je7CtoLR0wP
MAszBZjeTyRT2G0/XN9g1OIHy8llg9kB1ZZezwLWkIUunuxH5DcdiDBD5NRHGq7suv65YKnaSLSx
O5wM19FpTrFrGaX2OM9tBxK2S9UbSHQcSIwMJJloNRzgaDYM6hQKVUNnVXaP507JjmXUG9/QxQHp
UHKsF7mIaDlhVDQM7qGbeozaiBNILpVFPuomLx+PiLiWcc5bOzXjibjJKJ5KnE/DepRUtEw2D0I+
ppY3ZmKnk/QI0zFcDO6iJjPV1NRvmN2UiF7Majsku20Qreu1mdrchPhrqRo9/e9E76T0elEg7HFp
Nr/PYbLiIW1GBtGILoF6tTm931FPsW0ZzVkWclo4mjbNqGgpESYQBD4/Hs1WmH9Wi6jAvkHutPcd
AeQc5OgZmrejHCS620Nv+CNCvky+ElQPi2XxAykVNSuOcaPGISvjEFRBX+WfyCwk0hUzasMSfHiY
xdktw5YO0jNadiNISoEU4KZgEPturjvtrhv6Zi2d9KVQVb6X4D8xOcI1yjV0ZdDNXvF30vkKVL3h
6ckXHr7AW7FZtatUcrrMtxOlycc8YBgNKMfawQa9RwMnEnzVzu+L+9l6xvpna1FoLV50os91Fg1R
L3fWWRI4ChopHLtBaI3bBW03p1XdnPaXrwDwZTNRDaSPCmgxGIHUn4oiEz4v4aPxelTnhfaOkPLD
2A2987iQOQz9/7Et4jQ2h3xDyc3btfxpgdflv4u7BUa3u3X85Fua276TWrcSYkctG5qI3yzmxeIh
+n+xK24Vi9tKcV8Un78XPDEuoamFcpamxIsrfrxJuWYFzQVyLe3+IrjlJr3NL/gofh4XHyY6/QLf
/QNIWnzwHD0PToZWodNvP/QTvUpeWkAqvUPK391tSfLSIyIWey6Fd7kPNNHePc6jwvp90+aiKsJI
DxwijXJCJhAazWjp4jPDrJGEF8MjuMFUkNeFq8EQJ6ghyRVLuaKjXAklnZepPGMrthWatIPIwFSK
tOEw1gT7P/arnTeKIAb3kfIftuOCtNHOY+fRckcbCSUSBVVQAhQJEgcSyr/Hnz0P7wWWu/50RTL2
zoz9+bPHXiU4vSvM4Pv9g/B7R6FHObhdMyehDOP0E4YldKS0CZNmWn1MiBr7F9SmV53dlgaoNZhm
i54XVwR/fIFygQra4NG7nz5UxhVz0oTCh4NPGSrdPCPYjuBK9kj+bK9WZwKXIhiMI8NfM+q1DR71
1OVpMSgewZ81I+TAeEoq0dRA/HU00/ynUBdYyBAqWy88JhkqgpVLK2blDLbgilOjhN0xtJlyVIVR
jJThTeaReXPzhomzlT/D7mYtxShiZA6O/+ez9v6Odgz47b9ibwLbQkzIAWPiMBLS+8fLiy9vSWsi
xilqnoeYhlGGsaq0VC1ICbCJJTkPY3BdmXmnczOUZprQZYxZ6VEFLL3D6H/dMNrYdO/uFtDBMEYP
/1jgTnMq+v3W4eAHZ8ZeGj5tdlcjSoDZ/Lr/fP/zsXQDE78sMwrzrmwQWvCYYz0p6XXvSP24vHAm
c8wmBxI+QzAzyhOemyesLXOB1mQSBNTP8wcsZ0GECvU1yRpPI68JfBbQIEBrvH6y9tcusMDJHbjM
s/uxCSYRmCKwjEzmhq4IvOcCmpsALVWOzU4RhIQxTW0Jqdklh4Z4vbg1RG0URVFbbalNysotrOtx
7LcNvvnJ/tjgKlKCJQRTEczyBRvy1MIBQfETvWvSX9DcEq0+g0i+uMRZNqtZQS+2CdpO57UXNFny
edVNNwtssa4WEDnepzCkIWHyGuUi6HEoW3qkypk9luXKHu1iU+eD85ou4pEiFLusCOeMkLoykiFS
jBUMFacFZUV6nRUk+Dh814WlcKvoyRzybKT08i3NP6Dgke73cM6xc46dc+yIHPt2SLBnRUEeNzRJ
O0MKjTtFCtF9ObeSigRGkyq3aBZSZdcyge/nZzxplmVT0Sgsy6Z6V1iG7nDBMnR3C5b1LwrL+hnC
sn6JQKzMENp1OwvtuifOaz9riBsSlQSdpvMBmpVIDe9Dqt0uG6wMractdMNoe/37I8AAtUoEfA0K
ZW5kc3RyZWFtDQplbmRvYmoNCjE4IDAgb2JqDQo8PA0KL1Byb2NTZXQgWy9QREYgL1RleHQgXQ0K
L0ZvbnQgPDwNCi9GMyA0IDAgUg0KL0Y1IDUgMCBSDQovRjcgNiAwIFINCi9GMTAgMTkgMCBSDQo+
Pg0KL0V4dEdTdGF0ZSA8PA0KL0dTMSA3IDAgUg0KPj4NCj4+DQplbmRvYmoNCjIwIDAgb2JqDQo8
PA0KL1R5cGUgL0hhbGZ0b25lDQovSGFsZnRvbmVUeXBlIDENCi9IYWxmdG9uZU5hbWUgKERlZmF1
bHQpDQovRnJlcXVlbmN5IDYwDQovQW5nbGUgNDUNCi9TcG90RnVuY3Rpb24gL1JvdW5kDQo+Pg0K
ZW5kb2JqDQo3IDAgb2JqDQo8PA0KL1R5cGUgL0V4dEdTdGF0ZQ0KL1NBIGZhbHNlDQovT1AgZmFs
c2UNCi9IVCAvRGVmYXVsdA0KPj4NCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQov
U3VidHlwZSAvVHlwZTENCi9OYW1lIC9GMw0KL0VuY29kaW5nIDIxIDAgUg0KL0Jhc2VGb250IC9I
ZWx2ZXRpY2ENCj4+DQplbmRvYmoNCjUgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUg
L1R5cGUxDQovTmFtZSAvRjUNCi9FbmNvZGluZyAyMSAwIFINCi9CYXNlRm9udCAvSGVsdmV0aWNh
LUJvbGQNCj4+DQplbmRvYmoNCjYgMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5
cGUxDQovTmFtZSAvRjcNCi9FbmNvZGluZyAyMSAwIFINCi9CYXNlRm9udCAvVGltZXMtUm9tYW4N
Cj4+DQplbmRvYmoNCjE1IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0K
L05hbWUgL0Y5DQovRW5jb2RpbmcgMjEgMCBSDQovQmFzZUZvbnQgL1RpbWVzLUJvbGQNCj4+DQpl
bmRvYmoNCjE5IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UeXBlMQ0KL05hbWUg
L0YxMA0KL0VuY29kaW5nIDIxIDAgUg0KL0Jhc2VGb250IC9Db3VyaWVyDQo+Pg0KZW5kb2JqDQoy
MSAwIG9iag0KPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFsgMC9ncmF2ZS9hY3V0
ZS9jaXJjdW1mbGV4L3RpbGRlL21hY3Jvbi9icmV2ZS9kb3RhY2NlbnQvZGllcmVzaXMNCi9yaW5n
L2NlZGlsbGEvaHVuZ2FydW1sYXV0L29nb25lay9jYXJvbi9kb3RsZXNzaS9idWxsZXQvYnVsbGV0
DQovYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxl
dA0KL2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxsZXQvYnVsbGV0L2J1bGxldC9idWxs
ZXQNCiAzOS9xdW90ZXNpbmdsZSA5Ni9ncmF2ZSAxMjcvYnVsbGV0L2J1bGxldC9idWxsZXQvcXVv
dGVzaW5nbGJhc2UvZmxvcmluL3F1b3RlZGJsYmFzZQ0KL2VsbGlwc2lzL2RhZ2dlci9kYWdnZXJk
YmwvY2lyY3VtZmxleC9wZXJ0aG91c2FuZC9TY2Fyb24vZ3VpbHNpbmdsbGVmdC9PRQ0KL2J1bGxl
dC9idWxsZXQvYnVsbGV0L2J1bGxldC9xdW90ZWxlZnQvcXVvdGVyaWdodC9xdW90ZWRibGxlZnQv
cXVvdGVkYmxyaWdodA0KL2J1bGxldC9lbmRhc2gvZW1kYXNoL3RpbGRlL3RyYWRlbWFyay9zY2Fy
b24vZ3VpbHNpbmdscmlnaHQvb2UNCi9idWxsZXQvYnVsbGV0L1lkaWVyZXNpcy9zcGFjZSAxNjQv
Y3VycmVuY3kgMTY2L2Jyb2tlbmJhciAxNjgvZGllcmVzaXMvY29weXJpZ2h0DQovb3JkZmVtaW5p
bmUgMTcyL2xvZ2ljYWxub3QvaHlwaGVuL3JlZ2lzdGVyZWQvbWFjcm9uL2RlZ3JlZS9wbHVzbWlu
dXMvdHdvc3VwZXJpb3INCi90aHJlZXN1cGVyaW9yL2FjdXRlL211IDE4My9wZXJpb2RjZW50ZXJl
ZC9jZWRpbGxhL29uZXN1cGVyaW9yL29yZG1hc2N1bGluZSAxODgvb25lcXVhcnRlcg0KL29uZWhh
bGYvdGhyZWVxdWFydGVycyAxOTIvQWdyYXZlL0FhY3V0ZS9BY2lyY3VtZmxleC9BdGlsZGUvQWRp
ZXJlc2lzL0FyaW5nDQovQUUvQ2NlZGlsbGEvRWdyYXZlL0VhY3V0ZS9FY2lyY3VtZmxleC9FZGll
cmVzaXMvSWdyYXZlL0lhY3V0ZQ0KL0ljaXJjdW1mbGV4L0lkaWVyZXNpcy9FdGgvTnRpbGRlL09n
cmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlDQovT2RpZXJlc2lzL211bHRpcGx5L09zbGFz
aC9VZ3JhdmUvVWFjdXRlL1VjaXJjdW1mbGV4L1VkaWVyZXNpcy9ZYWN1dGUNCi9UaG9ybi9nZXJt
YW5kYmxzL2FncmF2ZS9hYWN1dGUvYWNpcmN1bWZsZXgvYXRpbGRlL2FkaWVyZXNpcy9hcmluZw0K
L2FlL2NjZWRpbGxhL2VncmF2ZS9lYWN1dGUvZWNpcmN1bWZsZXgvZWRpZXJlc2lzL2lncmF2ZS9p
YWN1dGUNCi9pY2lyY3VtZmxleC9pZGllcmVzaXMvZXRoL250aWxkZS9vZ3JhdmUvb2FjdXRlL29j
aXJjdW1mbGV4L290aWxkZQ0KL29kaWVyZXNpcy9kaXZpZGUvb3NsYXNoL3VncmF2ZS91YWN1dGUv
dWNpcmN1bWZsZXgvdWRpZXJlc2lzL3lhY3V0ZQ0KL3Rob3JuL3lkaWVyZXNpcw0KXQ0KPj4NCmVu
ZG9iag0KMSAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDggMCBSDQovUmVzb3VyY2Vz
IDMgMCBSDQovQ29udGVudHMgMiAwIFINCj4+DQplbmRvYmoNCjkgMCBvYmoNCjw8DQovVHlwZSAv
UGFnZQ0KL1BhcmVudCA4IDAgUg0KL1Jlc291cmNlcyAxMSAwIFINCi9Db250ZW50cyAxMCAwIFIN
Cj4+DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgOCAwIFINCi9S
ZXNvdXJjZXMgMTQgMCBSDQovQ29udGVudHMgMTMgMCBSDQo+Pg0KZW5kb2JqDQoxNiAwIG9iag0K
PDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDggMCBSDQovUmVzb3VyY2VzIDE4IDAgUg0KL0NvbnRl
bnRzIDE3IDAgUg0KPj4NCmVuZG9iag0KOCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlcw0KL0tpZHMg
WzEgMCBSIDkgMCBSIDEyIDAgUiAxNiAwIFJdDQovQ291bnQgNA0KL01lZGlhQm94IFswIDAgNjEy
IDc5Ml0NCj4+DQplbmRvYmoNCjIyIDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9QYWdlcyA4
IDAgUg0KPj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8DQovQ3JlYXRpb25EYXRlIChEOjE5MTAwMTEx
NjA5NDEzMykNCi9Qcm9kdWNlciAoXDM3NlwzNzdcMDAwQVwwMDBjXDAwMHJcMDAwb1wwMDBiXDAw
MGFcMDAwdFwwMDAgXDAwMERcMDAwaVwwMDBzXDAwMHRcMDAwaVwwMDBsXDAwMGxcMDAwZVwwMDBy
XDAwMCBcMDAwM1wwMDAuXDAwMDBcMDAwMVwwMDAgXDAwMGZcMDAwb1wwMDByXDAwMCBcMDAwV1ww
MDBpXDAwMG5cMDAwZFwwMDBvXDAwMHdcMDAwcykNCi9DcmVhdG9yIChQU0NSSVBULkRSViBWZXJz
aW9uIDQuMCkNCi9UaXRsZSAoTWljcm9zb2Z0IFdvcmQgLSBTU1JBY2Nlc3MuZG9jKQ0KPj4NCmVu
ZG9iag0KeHJlZg0KMCAyNA0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDQwOTMyIDAwMDAwIG4N
CjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwMDk0NSAwMDAwMCBuDQowMDAwMDM4OTYxIDAwMDAw
IG4NCjAwMDAwMzkwNjcgMDAwMDAgbg0KMDAwMDAzOTE3OCAwMDAwMCBuDQowMDAwMDM4ODgyIDAw
MDAwIG4NCjAwMDAwNDEyOTIgMDAwMDAgbg0KMDAwMDA0MTAyMCAwMDAwMCBuDQowMDAwMDAxMDcy
IDAwMDAwIG4NCjAwMDAwMDM5OTQgMDAwMDAgbg0KMDAwMDA0MTExMCAwMDAwMCBuDQowMDAwMDA0
MTExIDAwMDAwIG4NCjAwMDAwMDY4NDggMDAwMDAgbg0KMDAwMDAzOTI4NiAwMDAwMCBuDQowMDAw
MDQxMjAxIDAwMDAwIG4NCjAwMDAwMDY5ODggMDAwMDAgbg0KMDAwMDAzODYwOCAwMDAwMCBuDQow
MDAwMDM5Mzk0IDAwMDAwIG4NCjAwMDAwMzg3NDkgMDAwMDAgbg0KMDAwMDAzOTUwMCAwMDAwMCBu
DQowMDAwMDQxNDAxIDAwMDAwIG4NCjAwMDAwNDE0NTcgMDAwMDAgbg0KdHJhaWxlcg0KPDwNCi9T
aXplIDI0DQovUm9vdCAyMiAwIFINCi9JbmZvIDIzIDAgUg0KL0lEIFs8YjA4MGJlN2UyMTgwZDQ2
ZmU1ODM2NjhlNDkxMzQ3ZTQ+PGIwODBiZTdlMjE4MGQ0NmZlNTgzNjY4ZTQ5MTM0N2U0Pl0NCj4+
DQpzdGFydHhyZWYNCjQxNzg3DQolJUVPRg0K
--385491158.974670468406.JavaMail.root@web589-mc--



From owner-ietf-ipsra@mail.vpnc.org  Fri Nov 24 19:25:24 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05040
	for <ipsra-archive@odin.ietf.org>; Fri, 24 Nov 2000 19:25:23 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20680
	for ietf-ipsra-bks; Fri, 24 Nov 2000 15:59:56 -0800 (PST)
Received: from goofy.hyperthought.com (c31736-a.frmt1.sfba.home.com [24.1.105.178])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20676
	for <ietf-ipsra@vpnc.org>; Fri, 24 Nov 2000 15:59:55 -0800 (PST)
Received: from hyperthought.com (IDENT:scott@localhost [127.0.0.1])
	by goofy.hyperthought.com (8.9.3/8.9.3) with ESMTP id RAA01593
	for <ietf-ipsra@vpnc.org>; Fri, 24 Nov 2000 17:18:29 -0800
Message-ID: <3A1F1365.5C70B8BB@hyperthought.com>
Date: Fri, 24 Nov 2000 17:18:29 -0800
From: "Scott G. Kelly" <scott@hyperthought.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ietf-ipsra@vpnc.org
Subject: Re: draft-ietf-ipsra-reqmts-02.txt
References: <3A1F0442.355EF1EE@hyperthought.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>
Content-Transfer-Encoding: 7bit

(posting from home...)

This was apparently too late (by an hour or so) for publication, so I
have to resubmit it December 10. In any event, the text is available in
my previous post.

Scott


From owner-ietf-ipsra@mail.vpnc.org  Fri Nov 24 19:40:53 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07016
	for <ipsra-archive@odin.ietf.org>; Fri, 24 Nov 2000 19:40:52 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA19663
	for ietf-ipsra-bks; Fri, 24 Nov 2000 14:56:05 -0800 (PST)
Received: from goofy.hyperthought.com (c31736-a.frmt1.sfba.home.com [24.1.105.178])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA19657
	for <ietf-ipsra@vpnc.org>; Fri, 24 Nov 2000 14:55:57 -0800 (PST)
Received: from hyperthought.com (IDENT:scott@localhost [127.0.0.1])
	by goofy.hyperthought.com (8.9.3/8.9.3) with ESMTP id QAA01565;
	Fri, 24 Nov 2000 16:13:54 -0800
Message-ID: <3A1F0442.355EF1EE@hyperthought.com>
Date: Fri, 24 Nov 2000 16:13:54 -0800
From: "Scott G. Kelly" <scott@hyperthought.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: "Internet-Drafts@ietf.org" <Internet-Drafts@ietf.org>
CC: ietf-ipsra@vpnc.org, skelly@redcreek.com
Subject: draft-ietf-ipsra-reqmts-02.txt
Content-Type: multipart/mixed;
 boundary="------------41262999D822C0FFD5D36F1B"
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

This is a multi-part message in MIME format.
--------------41262999D822C0FFD5D36F1B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dear ID Editor,

Please publish the attached draft as draft-ietf-ipsra-reqmts-02.txt.
This is a work item of the ipsec remote access working group (ipsra),
and updates an existing draft. Please announce the publication to the
ipsra mailing list at ietf-ipsra@vpnc.org.

Thanks!

Scott
--------------41262999D822C0FFD5D36F1B
Content-Type: text/plain; charset=us-ascii;
 name="draft-ietf-ipsra-reqmts-02.txt"
Content-Disposition: inline;
 filename="draft-ietf-ipsra-reqmts-02.txt"
Content-Transfer-Encoding: 7bit




IPsec Remote Access  Working Group                 Scott Kelly, RedCreek
INTERNET-DRAFT                                 Sankar Ramamoorthi, Nexsi
draft-ietf-ipsra-reqmts-02.txt                            November, 2000


             Requirements for IPsec Remote Access Scenarios


Status of This Memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026]. Internet Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and working groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at

   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Comments on this document should be sent to the IETF IPsec remote
   access discussion list (ietf-ipsra@vpnc.org).


Abstract

   IPsec offers much promise as a secure remote access mechanism.
   However, there are a number of differing remote access scenarios,
   each having some shared and some unique requirements. A thorough
   understanding of these requirements is necessary in order to
   effectively evaluate the suitability of a specific set of mechanisms
   for any particular remote access scenario. This document enumerates
   the requirements for a number of common remote access scenarios.










Kelly, Ramamoorthi          Expires May 2001                   [Page 1]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


                             Table of Contents

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
1.4 Document Organization  . . . . . . . . . . . . . . . . . . . . .   5
2. Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
2.1 Endpoint Authentication  . . . . . . . . . . . . . . . . . . . .   6
2.1.1 Machine-Level Authentication . . . . . . . . . . . . . . . . .   7
2.1.2 User-Level Authentication  . . . . . . . . . . . . . . . . . .   8
2.1.3 Combined User/Machine Authentication . . . . . . . . . . . . .   8
2.1.4 Remote Access Authentication . . . . . . . . . . . . . . . . .   9
2.1.5 Compatibility With Legacy Mechanisms . . . . . . . . . . . . .  10
2.2 Remote Host Configuration  . . . . . . . . . . . . . . . . . . .  10
2.3 Security Policy Configuration  . . . . . . . . . . . . . . . . .  12
2.4 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
2.5 Intermediary Traversal . . . . . . . . . . . . . . . . . . . . .  13
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
3.1 Telecommuters (Dialup/DSL/Cablemodem)  . . . . . . . . . . . . .  14
3.1.1 Endpoint Authentication Requirements . . . . . . . . . . . . .  15
3.1.2 Device Configuration Requirements  . . . . . . . . . . . . . .  17
3.1.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  18
3.1.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  19
3.1.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  20
3.2 Corporate to Remote Extranet . . . . . . . . . . . . . . . . . .  20
3.2.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  21
3.2.2 Device Configuration Requirements  . . . . . . . . . . . . . .  21
3.2.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  22
3.2.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  22
3.2.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  22
3.3 Extranet Laptop to Home Corporate Net  . . . . . . . . . . . . .  23
3.3.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  23
3.3.2 Device Configuration Requirements  . . . . . . . . . . . . . .  24
3.3.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  24
3.3.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  25
3.3.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  25
3.4 Extranet Desktop to Home Corporate Net . . . . . . . . . . . . .  26
3.4.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  26
3.4.2 Device Configuration Requirements  . . . . . . . . . . . . . .  27
3.4.3 Policy Configuration Requirements  . . . . . . . . . . . . . .  27
3.4.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  27
3.4.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  27
3.5 Remote Dialup Laptop (Road Warrior) Access . . . . . . . . . . .  28
3.6 Public System to Corporate Network . . . . . . . . . . . . . . .  28
3.6.1 Authentication Requirements  . . . . . . . . . . . . . . . . .  28
3.6.2 Device Configuration Requirements  . . . . . . . . . . . . . .  30
3.6.3 Policy  Configuration Requirements . . . . . . . . . . . . . .  30
3.6.4 Auditing Requirements  . . . . . . . . . . . . . . . . . . . .  30

Kelly, Ramamoorthi          Expires May 2001                   [Page 2]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000

3.6.5 Intermediary Traversal Requirements  . . . . . . . . . . . . .  30
4. Scenario Commonalities  . . . . . . . . . . . . . . . . . . . . .  30
5. Security Considerations . . . . . . . . . . . . . . . . . . . . .  31
6. Editors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  31
7. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  32
9. Full Copyright Statement  . . . . . . . . . . . . . . . . . . . .  32
Appendix A: Change Log . . . . . . . . . . . . . . . . . . . . . . .  32



































Kelly, Ramamoorthi          Expires May 2001                   [Page 3]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


1. Introduction

   In the past, remote access has typically been characterized by dial-
   up users accessing the corporate network via the Public Switched
   Telephone Network (PSTN), with the dial-up connection terminating at
   a Network Access Server (NAS) within the corporate domain. The
   protocols facilitating this have usually been PPP-based, and access
   control, authorization, and accounting functions have typically been
   provided using one or more of a number of available mechanisms,
   including RADIUS [RADIUS].

   In some cases, PPP-based tunneling mechanisms have been used to
   provide remote access by allowing the user to first dial into a local
   ISP account, and then tunnel an additional PPP connection over the
   Internet into the target network. While these mechanisms have been
   lacking in terms of security features, the increasing availability of
   IPsec renders it possible to provide more secure remote access to the
   corporate resources via the Internet.

   Remote access via the Internet has numerous benefits, financial and
   otherwise. However, security is paramount, and this presents strong
   incentives for migration to an IPsec-based remote access model.
   Meeting the security requirements of various classes of remote access
   users presents a number of challenges. It is the aim of this document
   to explore and enumerate the requirements of various IPsec remote
   access scenarios, without suggesting particular solutions for them.


1.1 Requirements Terminology

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [3].

1.2 Reader Prerequisites

   Reader familiarity with RFCs 2401-2412 is a minimum prerequisite to
   understanding the concepts discussed here. Familiarity with concepts
   relating to Public Key Infrastructures (PKIs) is also necessary.
   Familiarity with RADIUS, PPP, PPTP, L2F, L2TP, and other remote
   access support protocols will also be helpful, though not strictly
   necessary.

1.3 General Terminology

   o Remote Access - this term is used to refer to the case in which
     the remote user does not necessarily reside at a fixed location,
     i.e. in which the user's IP address is not fixed, and therefore



Kelly, Ramamoorthi          Expires May 2001                   [Page 4]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


     usually not known prior to connection establishment.

   o Secure Remote Access - this term refers to remote access which is
     secured using elements of the IPsec protocol suite.

   o IPsec Remote Access Client (IRAC)- this term is used to refer to
     the remote access user's system.

   o IPsec Remote Access Server (IRAS) - this term refers to the device
     providing access to the corporate network. An alternative term
     is "Security Gateway".

   o Security GateWay (SGW) - this refers to the device providing
     access to the corporate network. An alternative term is IRAS.

   o Virtual IP address (VIP) - this term describes an address on
     the local subnet which is assigned to a remote client,
     giving the appearance that the remote client resides on
     the local subnet.

   o Machine-Level Authentication - this term describes the
     case where the identity of a machine is verified by virtue
     of the machine's possession and application of some
     combination of authenticators. For a more complete definition,
     see section 2.

   o User-Level Authentication - this term describes the case
     where the identity of a user (as opposed to that of a machine)
     is verified by virtue of the user's possession and application
     of some combination of authenticators. For a more complete
     definition, see section 2.


1.4 Document Organization

   The balance of this document is organized as follows: First, there is
   a general overview of the basic requirements categories, including
   definitions relevant to these categories. Following this is a section
   devoted to each remote access scenario. Within each of these sections
   there are subsections detailing requirements specific to that
   scenario in each of the following areas: endpoint authentication,
   remote host configuration, policy configuration, auditing, and
   intermediary traversal.

2. Overview

   In a very general sense, all secure remote access scenarios have a
   similar high-level appearance:



Kelly, Ramamoorthi          Expires May 2001                   [Page 5]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


                                         target network
                                              |
                                              |   +---+
   +-------------+             +-----------+  |---|   |
   |remote access|  internet   | security  |  |   +---+
   |   client    |=============| gateway   |--|
   |   (IRAC)    |             |(SGW/IRAS) |  |   +---+
   +-------------+             +-----------+  |---|   |
                                              |   +---+


   In all cases, a remote client wishes to securely access resources
   either behind a SGW or on an IPsec protected host, and/or wishes to
   provide other (specific) systems with secure access to the client's
   own resources. There are numerous details which may differ, depending
   on the particular scenario. For example, the IRAC may be within
   another corporate network, or connected to an ISP via dialup, DSL, or
   CATV media. There may be additional intermediaries between the remote
   client and the security gateway, but ultimately, all of these
   configurations may be viewed somewhat equivalently from a high level.

   In general, there are several basic categories of requirements
   relevant to secure remote access scenarios, including endpoint
   authentication, remote host configuration, security policy
   configuration, auditing, and intermediary traversal. Endpoint
   authentication refers to verification of the identities of the
   communication partners (e.g. the IRAC and the IRAS).  Remote host
   configuration refers to the device configuration parameters of the
   IRAC system. Security policy configuration refers to IPsec policy
   configuration of both the security gateway and the remote host, and
   might also be termed "access control and authorization
   configuration".  Auditing refers to the generation and collection of
   connection status information which is required for the purpose of
   maintaining the overall security and integrity of the connected
   networks. Intermediary traversal refers to the ability to pass
   secured traffic across intermediaries, some of which may modify the
   packets in some manner. Such intermediaries include NAPT and firewall
   devices. These various categories are treated in more detail below.


2.1 Endpoint Authentication

   Before discussing endpoint authentication with respect to remote
   access, it is important to distinguish between data source
   authentication and end user authentication. Data source
   authentication in the IPsec context consists in providing assurance
   that a network packet originates from a specific endpoint, typically
   a user, host, or application. IPsec offers mechanisms for this via AH



Kelly, Ramamoorthi          Expires May 2001                   [Page 6]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   or ESP. End user authentication within the IPsec context consists in
   providing assurance that the endpoint is what or who it claims to be.
   IPsec currently offers mechanisms for this as part of IKE  [IKE].

   While the two types of authentication differ, they are not unrelated.
   In fact, data source authentication relies upon endpoint
   authentication, because it is possible to inject packets with a
   particular IP address into the internet from many arbitrary
   locations, so that we cannot be certain in many instances that a
   packet actually originates from a particular host, or even from the
   network upon which that host resides.  To resolve this, one must
   first authenticate the particular endpoint somehow, and then bind the
   addressing information (e.g. IP address, protocol, port) of this
   endpoint into the trust relationship established by the
   authentication process.

   In the context of secure remote access, the authenticated entity may
   be a machine, a user (application), or both. The authentication
   methods currently supported by IPsec range from preshared secrets to
   various signature and encryption schemes employing private keys and
   their corresponding public key certificates. These mechanisms may be
   used to authenticate the end user alone, the device alone, or both
   the end user and the device. These are each discussed in more detail
   below.

2.1.1 Machine-Level Authentication

   In the case where no user input is required in order for an
   authentication credential to be used, the entity authenticated will
   primarily be the device in which the credential is stored, and the
   level of derived assurance regarding this authentication is directly
   related to how securely the machine's credential is maintained during
   both storage and use. That is, a shared secret or a private key
   corresponding to a public key certificate may be either stored within
   the device or contained in another device which is securely
   accessible by the device (e.g. a smartcard). If the knowledge
   required for the use of such authentication credentials is entirely
   contained within the subject device (i.e. no user input is required),
   then it is problematic to state that such credential usage
   authenticates anything other than the subject device.

   In some cases, a user may be required to satisfy certain criteria
   prior to being given access to stored credentials. In such cases, the
   level of user authentication provided by the use of such credentials
   is somewhat difficult to derive. If sufficiently strong access
   controls exist for the system housing the credential, then there may
   be a strong binding between the authorized system user and the
   credential. However, at the time the credential is presented, the



Kelly, Ramamoorthi          Expires May 2001                   [Page 7]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   IRAS itself has no such assurance. That is, the IRAS in isolation may
   have some level of assurance that a particular device (the one in
   which the credential resides) is the one from which access is being
   attempted, but there is no explicit assurance regarding the identity
   of the user of the system. In order for the IRAS to derive additional
   assurance regarding the user identity, an additional user credential
   of some sort would be required. This is discussed further below.


2.1.2 User-Level Authentication

   In some cases, the user may possess an authentication token
   (preshared key, private key, passphrase, etc.), and may provide this
   or some derivative of this whenever authentication is required. If
   this token or derivative is delivered directly to the other endpoint
   without modification by the IRAC system, and if the IRAC system
   provides no further credentials of its own, then it is the user alone
   which has been authenticated to some degree. That is, while there may
   be some assurance as to the network address from which the user is
   originating packets, there is no assurance as to the particular
   machine from which the user is attempting access.


2.1.3 Combined User/Machine Authentication

   To authenticate both the user and the system, user input of some sort
   is required in addition to a credential which is securely stored upon
   the device. In some cases, such user input may be used in order to
   "complete" the credential stored on the device (e.g. a private key is
   password-encrypted), while in others the user's input is supplied
   independently of the stored credential. In the case where the
   passphrase is applied to the credential prior to use, the level of
   assurance derived from successful application of the credential
   varies according to your viewpoint.

   From the perspective of a system consisting of user, IRAC, IRAS, and
   a collection of system protections and security procedures, it may be
   said that the user has been authenticated to an extent which depends
   upon the strength of the security procedures and system protections
   which are in place. However, from the perspective of the IRAS alone,
   there is little assurance with respect to user identity. That is,
   schemes requiring that stored credentials be modified by user input
   prior to use may only be said to provide user-level authentication
   within the context of the larger system, and then, the level of
   assurance derived is directly proportional to the weakest security
   attribute of the entire system.

   When considering remote access from a general perspective,



Kelly, Ramamoorthi          Expires May 2001                   [Page 8]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   assumptions regarding the overall system are liable to prove
   incorrect. This is because the IRAS and the IRAC may not be within
   the same domain of control; extranet scenarios are a good example of
   this. Hence, the most desirable joint user/machine authentication
   mechanisms in this context are those which provide a high level of
   assurance to both the IRAS and the IRAC, independently of the larger
   system of which the user, IRAS, and IRAC are a part.


2.1.4 Remote Access Authentication

   In the general case for remote access, authentication requirements
   are typically asymmetric.  From the IRAC's perspective, it is
   important to ensure that the IRAS at the other end of the connection
   is indeed what it seems to be, and not some rogue system masquerading
   as the SGW. That is, the IRAC requires machine-level authentication
   for the IRAS.  This is fairly straightforward, given the
   authentication mechanisms supported by IKE and IPsec. Further, this
   sort of authentication tends to persist through time, although the
   extent of this persistence depends upon the mechanism chosen.

   While machine-level authentication for the IRAS is sufficient, this
   is not the case for the IRAC. Here, it is often important to know
   that the entity at the other end of the connection is one who is
   authorized to access local resources rather than someone who happened
   upon an unoccupied but otherwise authorized system, or a malicious
   trojan horse application on that user's system, or some other
   unauthorized entity. Authenticating the user presents different
   requirements from authenticating the user's machine.  It requires
   some form of user input, and often must be periodically renewed.

   In situations where a high level of physical security does not exist,
   it is common to require a user-input secret as part of the
   authentication process, and then to periodically renew the
   authentication. Furthermore, since such circumstances may include the
   possibility of the presence of a trojan horse application on the IRAC
   system, one-time passphrase mechanisms are often advisable. Choosing
   passphrase mechanisms and renewal intervals which provide an
   acceptable level of risk, but which do not annoy the user too much,
   may be challenging. It should be obvious that even this approach
   offers limited assurance in many cases.

   Clearly, there are variable assurance levels which are attainable
   with the various endpoint authentication techniques, and none of the
   techniques discussed offer absolute assurance. Also, there are
   variations in the authentication requirements among different remote
   access scenarios. This means there is no "cookie cutter" solution for
   this problem, and that individual scenarios must be carefully



Kelly, Ramamoorthi          Expires May 2001                   [Page 9]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   examined in order to derive specific requirements for each. These are
   examined on a case by case basis below in the detailed scenario
   descriptions.

2.1.5 Compatibility With Legacy Mechanisms

   There are a number of currently deployed remote access mechanisms
   which were installed prior to the deployment of IPsec. Typically,
   these are dialup systems which rely upon RADIUS for user
   authentication, but there are other mechanisms as well. An ideal
   IPsec remote access solution might utilize the components of the
   underlying user authentication framework without modification.
   Inasmuch as this is possible, this should be a goal. However, there
   may be cases where this simply cannot be accomplished, due to
   security and/or other considerations. In such cases, the IPsec remote
   access framework should be designed to accommodate migration from
   these mechanisms as painlessly as is possible.

   In general, proposed IPsec remote access mechanisms should meet the
   following goals:

     o should provide direct support for legacy user authentication
       systems such as RADIUS

     o should encourage migration from existing low-entropy
       password-based systems to more secure authentication systems

     o if legacy support cannot be provided without some sort of
       migration, the impact of such migration should be minimized

     o user authentication information must be protected against
       eavesdropping and replay (including the user identity)

     o single sign-on capability should be provided in configurations
       employing load-balancing and/or redundancy

     o n-factor authentication mechanisms should be supported



2.2 Remote Host Configuration

   Remote host configuration refers to the network-related device
   configuration of the client system. This configuration may be fixed
   or dynamic. It may be completely provided by the administrator of the
   network upon which the remote user currently resides (e.g. the ISP),
   or it may be partially provided by that administrator, with the
   balance provided by an entity on the remote corporate network which



Kelly, Ramamoorthi          Expires May 2001                  [Page 10]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   the client is accessing. In general, this configuration may include
   the following:

     o IP address(es)
     o Subnet mask(s)
     o Broadcast address(es)
     o Host name
     o Domain name
     o Time offset
     o Servers (e.g. SMTP, POP, WWW, DNS/NIS, LPR,
       syslog, WINS, NTP, etc. )
     o Router(s)
     o Router discovery options
     o Static routes
     o MTU
     o Default TTL
     o Source routing options
     o IP Forwarding enable/disable
     o PMTU options
     o ARP cache timeout
     o X Windows options
     o NIS options
     o NetBIOS options
     o Vendor-specific options
     o (other options)

   Cases where such configuration is fixed are uninteresting; it is the
   cases where specific IRAC configuration occurs as a result of remote
   access with which we are concerned. For example, in some cases the
   IRAC may be assigned a "virtual address", giving the appearance that
   it resides on the (local) corporate network:

                                          corporate net
    +------------------+                      |
    |  Remote Access   |        +--------+    |   ( ~ ~ ~ ~ ~ )
    |+-------+ Client  |        |        |    |   (   IRAC    )
    ||virtual|         |        |security|    |~~~(  virtual  )
    || host  |         |--------|gateway |    |   (  presence )
    ||       |<================>|        |----|     ~ ~ ~ ~ ~
    |+-------+         |--------|        |    |
    +------------------+   ^    +--------+    |   +--------+
                           |                  |---|  local |
                         IPsec tunnel         |   |   host |
                         with encapsulated    |   +--------+
                         traffic inside


   In this case, the IRAC system begins with an externally routable



Kelly, Ramamoorthi          Expires May 2001                  [Page 11]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   address. An additional internal corporate address is assigned to the
   IRAC, and packets containing this assigned address are encapsulated,
   with the outer headers containing the IRAC's routable address, and
   forwarded to the IRAS through the tunnel. This provides the IRAC with
   a virtual presence on the corporate network via an IPsec tunnel. Note
   that the IRAC now has two active addresses: the ISP-assigned address,
   and the VIP.

   Having obtained this virtual presence on the corporate network, the
   IRAC may now require other sorts of topology-related configuration,
   e.g. default routers, DNS server(s), etc., just as a dynamically
   configured host which physically resides upon the corporate network
   would. It is this sort of configuration with which this requirements
   category is concerned.



2.3 Security Policy Configuration

   Security policy configuration refers to IPsec access policies for
   both the remote access client and the security gateway. It may be
   desirable to configure access policies on connecting IRAC systems
   which will protect the corporate network. For example, since a client
   has access to the internet (via its routable address), other systems
   on the internet also have some level of reciprocal access to the
   client. In some cases, it may be desirable to block this internet
   access (or force it to pass through the tunnel) while the client has
   a tunneled connection to the corporate network. This is a matter of
   client security policy configuration.

   For the security gateway, it may also be desirable to dynamically
   adjust policies based upon the user with which a connection has been
   established. For example, say there are two remote users, named Alice
   and Bob. We wish to provide Alice with unrestricted access to the
   corporate network, while we wish to restrict Bob's access to specific
   segments. One way to accomplish this would be to statically assign
   internal corporate "virtual" addresses to each user in a one-to-one
   mapping, so that each user always has the same address. Then, a
   particular user's access could be controlled via policies based upon
   the particular address. However, this does not scale well.

   A more scalable solution for remote client access control would be to
   dynamically assign IP addresses from a specific pool based upon the
   authenticated endpoint identity, with access to specific resources
   controlled by address-based policies in the SGW. This is very similar
   to the static mapping described above, except that a given group of
   users (those with identical access controls) would share a given pool
   of IP addresses (those which are granted the required access), rather



Kelly, Ramamoorthi          Expires May 2001                  [Page 12]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   than a given user always mapping to a given address. However, this
   also has scaling issues, though not as pronounced as for the static
   mapping.

   Alternatively, an arbitrary address could be assigned to a user, with
   the security gateway's policy being dynamically updated based upon
   the identity of the remote client (and its assigned virtual address)
   to permit access to particular resources. In these cases, the
   relevant security policy configuration is specific to the IRAS,
   rather than to the IRAC. Both IRAS and IRAC security policy
   configuration are encompassed by this requirements category.


2.4 Auditing

   Auditing is used here to refer to the collection and reporting of
   connection status information by the IRAS, for the purpose of
   maintaining the security and integrity of the network the IRAS
   protects. For remote access, the following auditing information is
   useful from a security perspective:

     o connection start time
     o connection end time

   Note that the requirement for a connection-end-time attribute implies
   the need for a connection heartbeat mechanism of some sort so that
   the IRAS can accurately determine this quantity in cases where the
   IRAC does not explicitly terminate the connection. Also note that the
   heartbeat mechanism in this case is always directed from the IRAC to
   the IRAS.

   In some cases, use of a heartbeat may negatively influence a
   connection. For example, if the heartbeat interval is very short, and
   the connection is reset after loss of very few heartbeat packets,
   there is a possibility that network congestion could lead to
   unnecessary connection resets. The heartbeat interval and reset
   threshold should be chosen with this in mind, and it should be
   possible to adjust these quantities either through configuration or
   negotiation.


2.5 Intermediary Traversal

   Intermediary traversal is used here to refer to passing a secured
   data stream through an intermediary such as a firewall or NAPT
   device. In the case of firewalls, numerous deployed products do not
   recognize the IPsec protocol suite, making it difficult (sometimes
   impossible) to configure them to pass it through. In such cases, a



Kelly, Ramamoorthi          Expires May 2001                  [Page 13]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   mechanism is required for making the data stream appear to be of a
   type which the firewall is capable of managing.

   In the case of NAPT devices, there are a number of issues with
   attempting to pass an encrypted or authenticated data stream. For
   example, NAPT devices typically modify the source IP address and
   UDP/TCP port of outgoing packets, and the destination IP address and
   UDP/TCP port of incoming packets. Such modifications render the use
   of the AH protocol problematic. In the case of ESP, if encryption is
   employed the UDP/TCP port fields are unreadable (and unmodifiable),
   making meaningful translation by the NAPT device impossible. There
   are numerous other protocol-field combinations which suffer
   similarly. This requirements category is concerned with these issues.


3. Scenarios

   There are numerous remote access scenarios possible using IPsec. This
   section contains a brief summary enumeration of these, followed by a
   subsection devoted to each which explores the various requirements in
   terms of the categories defined above.

   The following scenarios are discussed:

     o dialup/dsl/cablemodem telecommuters using their own home
       systems to access corporate resources

     o extranet users using their corporate desktop systems to
       access the remote company network of a business partner

     o extranet users using their own laptop within another
       company's network to access their home corporate network

     o extranet users using a business partner's system (on that
       partner's network) to access their home corporate network

     o road warriors using their own laptop systems to access
       corporate resources via an arbitrary ISP dialup connection

     o remote users using a borrowed system (e.g. an airport
       kiosk) to access corporate resources


3.1 Telecommuters (Dialup/DSL/Cablemodem)

   The telecommuter scenario is one of the more common remote access
   scenarios. The convenience and wide availability of internet access
   makes this an attractive option under many circumstances. Users may



Kelly, Ramamoorthi          Expires May 2001                  [Page 14]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   access the internet from the comfort of their homes or hotel rooms,
   and using this internet connection, access the resources of a
   corporate network. In some cases, dialup accounts are used to provide
   the initial internet access, while in others some type of "always-on"
   connection such as a DSL or CATV modem is used.

   The dialup and always-on cases are very similar, with two significant
   differences: address assignment mechanism, and connection duration.
   In most dialup cases, the IRAC's IP address is dynamically assigned
   as part of connection setup, and with fairly high likelihood, it is
   different each time the IRAC connects. DSL/CATV users, on the other
   hand, often have static IP addresses assigned to them, although
   dynamic assignment is on the increase. As for connection duration,
   dialup remote access connections are typically short-lived, while
   always-on connections may maintain remote access connections for
   significantly longer periods of time.

   The general configuration in either case looks like this:

                                              corporate net

                                                  |  +----+
     +-----+   +-----+      /---/ internet +---+  |--|    |
     |IRAC |---|modem|------|ISP|==========|SGW|--|  +----+
     +-----+   +-----+      /---/          +---+  |
                                                  |


   An alternative to this configuration entails placing a security
   gateway between the user's system and the modem, in which case this
   added SGW becomes the IRAC. This is currently most common in cases
   where DSL/CATV connections are used.

3.1.1 Endpoint Authentication Requirements

   The authentication requirements of this scenario depend in part upon
   the general security requirements of the network to which access is
   to be provided. Assuming that the corporate SGW is physically secure,
   machine authentication for the SGW is sufficient. If this assumption
   regarding physical security is incorrect, it is not clear that
   stronger authentication for the SGW could be guaranteed, and
   derivation of an effective mechanism for that case is beyond the
   scope of this document.

   For the IRAC, there are numerous threats to the integrity of the user
   authentication process. Due to the open nature of common consumer
   operating systems, some of these threats are quite difficult to
   protect against. For example, it is very difficult to assert with any



Kelly, Ramamoorthi          Expires May 2001                  [Page 15]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   level of certainty that a single user system which permits the
   downloading and running of arbitrary applications from the internet
   has not been compromised, and that a covert application is not
   monitoring and interacting with the user's data at any point in time.

   However, there are 3 general threats we might realistically hope to
   somehow mitigate with appropriate authentication mechanisms if we can
   assume that the system has not been compromised in this manner.
   First, there is the possibility that a secure connection is
   established for a particular user, but that someone other than the
   intended user is currently using that connection. Second, there is
   the possibility that the user's credential (password, hardware token,
   etc.)  has been somehow compromised, and is being used by someone
   other than the authorized user to gain access. Third, there is the
   possibility that the connection is being passively monitored prior to
   being secured, effectively eliminating the data confidentiality which
   the connection is supposed to provide.

   Mitigation of the first threat, the possiblity that someone other
   than the authorized user is currently using the connection,  requires
   periodic renewal of user authentication. It should be clear that
   machine authentication will not suffice in this case, and that
   requiring periodic re-entry of an unchanging user password (which may
   be written on a post-it note which is stuck to the user's monitor)
   will have limited effectiveness. Convincing verification of the
   continued presence of the authorized user will, in many cases,
   require periodic application of a time-variant credential.

   Mitigation of the second threat, credential compromise, is difficult,
   and depends upon a number of factors. If the IRAC system is running a
   highly secure operating system, then a time-variant credential may
   again offer some value.  A static password is clearly deficient in
   this scenario, since it may be subject to either online or offline
   guessing, and eventually compromised - which is the threat we are
   attempting to mitigate. However, if the IRAC operating system is not
   hardened,  the use of a time-variant credential is only effective if
   simultaneous access from more than one location is forbidden, and if
   the credential generation mechanism is not easily compromised.

   Mitigation of the third threat, passive monitoring,  requires that it
   not be possible to monitor the unprotected data externally via system
   emissions, and that the system be running a sufficiently secure
   operating system to protect the unsecured portion of the data stream
   against malicious code.  This is perhaps the most difficult of the
   listed threats to deal with, and it requires that the IRAS make some
   assumptions about the IRAC system.

   In order to provide assurance regarding mitigation of this (third)



Kelly, Ramamoorthi          Expires May 2001                  [Page 16]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   threat, a sufficiently secured operating system must have access to a
   machine credential, and this must be used to authenticate the system
   once system integrity has been verified. If further assurance
   regarding the user's identity is required in addition to this, it is
   possible that the IRAC system could provide such an assurance
   mechanism as part of its login procedure (prior to establishment of
   the remote access connection).  However, it is important to note that
   the IRAS derives no assurance from this, independently of the larger
   security system of which it is a part. If the IRAS requires
   independent assurance of the user identity, then some additional
   user-level authentication mechanism (e.g. a time-variant credential
   of some sort) must be combined with the IRAC machine authentication.

   To summarize, the following are the authentication requirements for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for user authentication SHOULD be provided
     o support for either user or machine authentication MUST
       be provided
     o support for machine authentication MUST be provided if
       protection from passive monitoring is desired. Further, such
       protection requires a that the IRAC be physically secured, and
       running a secure OS
     o support for user authentication MUST be provided if protection
       from unauthorized connection use is desired.
     o if user authentication is provided for short-lived dialup
       connections, periodic renewal MAY occur
     o if user authentication is provided for always-on connections,
       periodic renewal SHOULD occur



3.1.2 Device Configuration Requirements

   There are 2 possibilities for device configuration in the
   telecommuter scenario: either access to the corporate network is
   permitted for the native ISP-assigned address of the telecommuter's
   system, or the telecommuter's system is assigned a virtual address
   from within the corporate address space. In the first case, there are
   no device configuration requirements which are not already satisfied



Kelly, Ramamoorthi          Expires May 2001                  [Page 17]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   by the ISP.  However, this case is the exception, rather than the
   rule.

   The second case is far more common, due to the numerous benefits
   derived by providing the IRAC with a virtual presence on the
   corporate network. For example, the virtual presence allows the
   client to receive subnet broadcasts, which permits it to use WINS on
   the corporate network. In addition, if the IRAC tunnels all traffic
   to the corporate network, then the corporate policy can be applied to
   internet traffic to/from the IRAC.

   In this case, the IRAC requires, at minimum, assignment of a
   corporate IP address. Typically, the IRAC requires anywhere from
   several more to many more elements of configuration information,
   depending upon the corporate network's level of topological
   complexity. For a fairly complete list, see section 2.2.

   To summarize, the following are the device configuration requirements
   for the IRAC:

     o support for a virtual IP (VIP) address MAY be provided
     o if VIP support is provided, support for all device-related
        parameters listed in section 2.2 above SHOULD be provided
     o support for address assignment based upon authenticated
       identity SHOULD be provided
     o if authenticated address assignment is not supported, an
       identity-based dynamic policy update mechanism such as
       is described in [ARCH] MUST be supported.


3.1.3 Policy Configuration Requirements

   In terms of IRAC policy configuration, the most important issue
   pertains to whether the IRAC has direct internet access enabled (for
   browsing, etc.) while a connection to the corporate network exists.
   This is important since the fact that the IRAC has access to sites on
   the internet implies that those sites have some level of reciprocal
   access to the IRAC. It may be desirable to completely eliminate this
   type of access while a tunnel is active.

   Alternatively, the risks may be mitigated somewhat by forcing all
   non-corporate packets leaving the IRAC to first traverse the tunnel
   to the corporate network, where they may be subjected to corporate
   policy.  A second approach which carries a bit less overhead entails
   modifying the IRAC's policy configuration to reflect that of the
   corporation during the time the IRAC is connected to the corporate
   network. In this case, traffic is not forced to loop through the
   corporate site prior to exiting or entering the IRAC. This requires



Kelly, Ramamoorthi          Expires May 2001                  [Page 18]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   some sort of policy download (or modification) capability as part of
   the SA establishment process. A third approach is to provide a
   configuration variable for the IRAC which permits specification of
   "tunnel-all", or "block all traffic not destined for the corporate
   network while the SA is up".

   In terms of IRAS configuration, it may be necessary to dynamically
   update the security policy database (SPD) when the remote user
   connects. This is because transit selectors must be based upon
   network address parameters, but these cannot be known a priori in the
   remote access case. As is noted above, this may be avoided by
   provision of a mechanism which permits address assignment based upon
   authenticated identity.

   To summarize, the following are the policy configuration requirements
   for the IRAS and IRAC:

   IRAS
   ----

     o dynamic policy update mechanism based upon identity and
       assigned address MAY be supported.

     o if address assignment-based policy update mechanism is
       not supported, address assignment based upon authenticated
       identity SHOULD be supported.


   IRAC
   ----

     o IRAC SHOULD provide ability to configure for "tunnel-all"
       and/or "block-all" for traffic not destined for the
       remote network to which IPsec remote access is being
       provided.

     o support for dynamic IRAS update of IRAC policy MAY be provided.


3.1.4 Auditing Requirements

   For telecommuter sessions, session start/end times must be collected.
   Reliable derivation of session end time requires that the IRAC
   somehow periodically signify that the connection remains active. This
   is implied if the IRAS receives data from the IRAC over the
   connection, but in cases where no data is sent for some period of
   time, a signaling mechanism is required by which the IRAC indicates
   that the connection remains in use.



Kelly, Ramamoorthi          Expires May 2001                  [Page 19]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


3.1.5 Intermediary Traversal Requirements

   If the address assigned by the ISP to the IRAC system is globally
   routable, and no intermediate devices between the IRAC and the IRAS
   perform NAPT operations on the data stream, then there are no
   additional requirements.  If NAPT operations are performed on the
   data stream, some mechanism must be provided in order to render these
   modifications transparent to the IPsec implementation.


3.2 Corporate to Remote Extranet

   Extranets are becoming increasingly common, especially as IPsec
   becomes more widely deployed. In this scenario, a user from one
   corporation uses a local corporate system to access resources on
   another corporation's network. Typically, these corporations are
   cooperating on some level, but not to the degree that unbridled
   access between the two networks would be acceptable. Hence, this
   scenario is characterized by limited access. The general topological
   appearance is similar to this:


          CORP A                                CORP B
             |                                      |
    +----+   |                                      |  +-----+
    |USER|---|                                      |--| S1  |
    +----+   |   +------++              ++------+   |  +-----+
             |---|SGW/FW||===internet===||SGW/FW|---|
             |   +------++              ++------+   |  +-----+
             |     SGW-A                   SGW-B    |--| S2  |
             |                                      |  +-----+


   This is purposely simplified in order to illustrate some basic
   characteristics without getting bogged down in details. At the edge
   of each network is a combination security gateway and firewall
   device.  These are labeled "SGW-A" and "SGW-B". In this diagram,
   corporation B wishes to provide a user from corporation A with access
   to servers S1 and/or S2. This may be accomplished in one of several
   different ways:

   1) an end-to-end SA is formed from USER to S1 or S2

   2) a tunnel-mode SA is formed between SGW-A and SGW-B which only
      permits traffic between S1/S2 and USER.

   3) a tunnel-mode SA is formed between USER and SGW-B which only
      permits traffic between S1/S2 and USER.



Kelly, Ramamoorthi          Expires May 2001                  [Page 20]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   These various cases are individually discussed with respect to each
   requirements category below.

3.2.1 Authentication Requirements

   For the corporate extranet scenario, the authentication requirements
   vary slightly depending upon the manner in which the connection is
   accomplished. If only a particular user is permitted to access S1/S2,
   then user-level authentication is required. If connection types (1)
   or (3) are used, this may be accomplished in the same manner as it
   would be for a telecommuter. If connection type (2) is used, one of
   two things must occur: either SGW-A must provide some local mechanism
   for authenticating USER and SGW-B must trust this mechanism, or SGW-B
   must have some mechanism for authenticating USER independently of
   SGW-A.

   If access is permitted for anyone within corporation A, then machine
   authentication will suffice. However, this is highly unlikely. A
   slightly more likely situation might be one in which access is
   permitted to anyone within a particular organizational unit in
   corporation A. This case is very similar the single user access case
   discussed above, and essentially has the same requirements in terms
   of the mechanism required for SGW-A, although machine authentication
   might suffice if the organizational unit which is permitted access
   has a sufficient level of physical security. Again, this requires
   that corporation B trust corporation A in this regard.

   To summarize, the following are the authentication requirements, for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for either user or machine authentication MUST
       be provided
     o support for a combination of user and machine authentication
       SHOULD be provided
     o if user authentication is used, periodic renewal SHOULD occur


3.2.2 Device Configuration Requirements

   It is possible that corporation B would want to assign a virtual



Kelly, Ramamoorthi          Expires May 2001                  [Page 21]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   address to USER for the duration of the connection. The only way this
   could be accomplished would be if USER were a tunnel endpoint (e.g.
   in cases (1) and (3)). It is not clear what benefits, if any, this
   would offer.

   To summarize, the following are the device configuration requirements
   for the IRAC:

     o support for a virtual address MAY be provided
     o if VIP support is provided, support for all device-related
       parameters listed in section 2.2 above SHOULD be supported
     o support for address assignment based upon authenticated
       identity SHOULD be supported
     o if authenticated address assignment is not supported, an
       identity-based dynamic policy update mechanism such as
       is described in [ARCH] MUST be supported.


3.2.3 Policy Configuration Requirements

   Any of the cases discussed above would present some static policy
   configuration requirements. Case (1) would require that SGW-A and
   SGW-B permit IPsec traffic to pass between USER and S1/S2. Case (3)
   would have similar requirements, except that the IPsec traffic would
   be between USER and SGW-B. Case (2) would require that the
   appropriate transit traffic be secured between USER and S1/S2.

   None of these cases require dynamic policy configuration.

3.2.4 Auditing Requirements

   For cases (1) and (3),  session start/end times must collected.
   Reliable derivation of session end time requires that the IRAC
   somehow periodically signify that the connection remains active. This
   is implied if the IRAS receives data from the IRAC over the
   connection, but in cases where no data is sent for some period or
   time, a signaling mechanism is required by which the IRAC indicates
   that the connection remains in use.

   For case (2), the type(s) of required auditing data would depend upon
   whether traffic from multiple users were aggregated within a single
   tunnel or not. If so, the notion of individual connection start/stop
   times would be lost. If such measures are desired, this requires that
   per-user tunnels be set up between SGW-A and SGW-B, and that some
   sort of timeout interval be used to cause tunnel teardown when
   traffic does not flow for some interval of time.

3.2.5 Intermediary Traversal Requirements



Kelly, Ramamoorthi          Expires May 2001                  [Page 22]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   If the address assigned by the host network to the IRAC system is
   globally routable, and no intermediate devices between the IRAC and
   the IRAS perform NAPT operations on the data stream, then there are
   no additional requirements in this regard. If NAPT operations are
   performed on the data stream, some mechanism must be provided in
   order to render these modifications transparent to the IPsec
   implementation.

   If a firewall situated at the edge of the host network cannot be
   configured to pass protocols in the IPsec suite, then some mechanism
   must be provided which converts the data stream to one which the
   firewall may be configured to pass.  If the firewall can be
   configured to pass IPsec protocols, then this must be accomplished
   prior to connection establishment.


3.3 Extranet Laptop to Home Corporate Net

   The use of a laptop while visiting another corporation presents
   another increasingly common extranet scenario. In this case, a user
   works temporarily within another corporation, perhaps as part of a
   service agreement of some sort. The user brings along a CORP-A laptop
   which is assigned a CORP-B address either statically or dynamically,
   and the user wishes to securely access resources on CORP-A's network
   using this laptop. This scenario has the following appearance:

          CORP A                                CORP B
             |                                      |
    +----+   |                                      |  +--------+
    |POP |---|                                      |--| CORP-A |
    +----+   |   +------++              ++------+   |  | laptop |
             |---|SGW/FW||===internet===||SGW/FW|---|  +--------+
             |   +------++              ++------+   |
    +----+   |     SGW-A                   SGW-B    |
    |FTP |---|                                      |
    +----+   |                                      |


   This is very similar to the telecommuter scenario, but it differs in
   several important ways. First, in this case there is often a SGW
   and/or firewall at the edge of CORP-B's site. Second, there may be a
   significantly increased risk that a long-lived connection could
   become accessible to someone other than the intended user.

3.3.1 Authentication Requirements

   In most cases, the only acceptable connections from CORP-A's
   perspective are between the laptop and either SGW-A or the CORP-A



Kelly, Ramamoorthi          Expires May 2001                  [Page 23]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   servers the laptop wishes to access. Most of the considerations
   applied to the telecommuter also apply here, and user-level
   authentication is required to provide assurance that the user who
   initiated the connection is still the active user. As an added
   precaution, a combination of user-level and machine-level
   authentication may be warranted in some cases. Further, in either
   case this authentication should be renewed frequently.

   To summarize, the following are the authentication requirements, for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o support for machine authentication SHOULD be provided
     o support for user authentication MUST be provided
     o support for a combination of user and machine authentication
       SHOULD be provided
     o periodic renewal of user authentication MUST occur



3.3.2 Device Configuration Requirements

   The device configuration requirements in this scenario are the same
   as for the telecommuter, i.e. the laptop may be assigned a virtual
   presence on the corporate network, and if so, will require full
   infrastructure configuration.

   To summarize, the following are the device configuration requirements
   for the IRAC:

     o support for a virtual address MAY be provided
     o if VIP support is provided, support for all device-related
       parameters listed in section 2.2 above SHOULD be supported
     o support for address assignment based upon authenticated
       identity SHOULD be supported
     o if authenticated address assignment is not supported, an
       identity-based dynamic policy update mechanism such as
       is described in [ARCH] MUST be supported.


3.3.3 Policy Configuration Requirements



Kelly, Ramamoorthi          Expires May 2001                  [Page 24]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   The policy configuration requirements in this scenario differ from
   those of the telecommuter, in that the laptop cannot be assigned a
   policy which requires all traffic to be forwarded to CORP-A via the
   tunnel. This is due to the fact that the laptop has a CORP-B address,
   and as such, may have traffic destined to CORP-B. If this traffic
   were tunneled to CORP-A, there might be no return path to CORP-B
   except via the laptop. On the other hand, internet-bound traffic
   could be subjected to this restriction if desired, and/or all traffic
   other than that between CORP-A and the laptop could be blocked for
   the duration of the connection.

   IRAC
   ----

     o support for IRAS update of IRAC policy MAY be provided.

     o if IRAS update of IRAC policy is not supported, IRAC MAY
       support IRAS directives to "block-all" for non-tunneled
       traffic.

     o IRAC SHOULD provide ability to configure for "tunnel-all"
       and/or "block-all" for traffic not destined for the
       remote network to which IPsec remote access is being
       provided.



3.3.4 Auditing Requirements

     The auditing requirements in this scenario are the same as for the
     telecommuter scenario. Session start/end times must collected.
     Reliable derivation of session end time requires that the IRAC
     somehow periodically signify that the connection remains active.
     This is implied if the IRAS receives data from the IRAC over the
     connection, but in cases where no data is sent for some period or
     time, a signaling mechanism is required by which the IRAC indicates
     that the connection remains in use.


3.3.5 Intermediary Traversal Requirements

     If the address assigned by the host network to the IRAC system is
     globally routable, and no intermediate devices between the IRAC and
     the IRAS perform NAPT operations on the data stream, then there are
     no additional requirements in this regard. If NAPT operations are
     performed on the data stream, some mechanism must be provided in
     order to render these modifications transparent to the IPsec
     implementation.



Kelly, Ramamoorthi          Expires May 2001                  [Page 25]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


     If a firewall situated at the edge of the host network cannot be
     configured to pass protocols in the IPsec suite, then some
     mechanism must be provided which converts the data stream to one
     which the firewall may be configured to pass.  If the firewall can
     be configured to pass IPsec protocols, then this must be
     accomplished prior to connection establishment.


3.4 Extranet Desktop to Home Corporate Net

   This is very similar to the extranet laptop scenario discussed above,
   except that a higher degree of trust for CORP-B is required by CORP-
   A.  This scenario has the following appearance:

           CORP A                                CORP B
             |                                      |
    +----+   |                                      |  +--------+
    |POP |---|                                      |--| CORP-B |
    +----+   |   +------++              ++------+   |  |desktop |
             |---|SGW/FW||===internet===||SGW/FW|---|  +--------+
             |   +------++              ++------+   |
    +----+   |     SGW-A                   SGW-B    |
    |FTP |---|                                      |
    +----+   |                                      |



3.4.1 Authentication Requirements

   The authentication requirements for the desktop extranet scenario are
   very similar to those of the extranet laptop scenario discussed
   above.  The primary difference lies in the authentication type which
   may be used, i.e. in the laptop case, CORP-A can derive some
   assurance that the connection is coming from one of CORP-A's systems
   if a securely stored machine credential is stored on and used by on
   the laptop. In the desktop case this is not possible, since CORP-A
   does not own the IRAC system.

   To summarize, the following are the authentication requirements for
   the IRAS and IRAC:

   IRAS
   ----

     o machine authentication MUST be provided.

   IRAC
   ----



Kelly, Ramamoorthi          Expires May 2001                  [Page 26]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


     o support for machine authentication MAY be provided
     o support for user authentication MUST be provided
     o support for a combination of user and machine authentication
       MAY be provided
     o periodic renewal of user authentication MUST occur

3.4.2 Device Configuration Requirements

     The device configuration requirements in this scenario are the same
     as for the laptop extranet scenario, i.e. the desktop system may be
     assigned a virtual presence on the corporate network, and if so,
     will require full infrastructure configuration. However, this seems
     less likely than in the laptop scenario, given CORP-A's lack of
     control over the software configuration of CORP-B's desktop system.


3.4.3 Policy Configuration Requirements

     The policy configuration requirements are quite similar to those of
     the extranet laptop, except that in this scenario there is even
     less control over CORP-B's desktop than there would be over the
     laptop. This means it may not be possible to restrict traffic in
     any way at the desktop system.

3.4.4 Auditing Requirements

     The auditing requirements in this scenario are the same as for the
     telecommuter scenario. Session start/end times must collected.
     Reliable derivation of session end time requires that the IRAC
     somehow periodically signify that the connection remains active.
     This is implied if the IRAS receives data from the IRAC over the
     connection, but in cases where no data is sent for some period or
     time, a signaling mechanism is required by which the IRAC indicates
     that the connection remains in use.

3.4.5 Intermediary Traversal Requirements

     If the address assigned by the host network to the IRAC system is
     globally routable, and no intermediate devices between the IRAC and
     the IRAS perform NAPT operations on the data stream, then there are
     no additional requirements in this regard. If NAPT operations are
     performed on the data stream, some mechanism must be provided in
     order to render these modifications transparent to the IPsec
     implementation.

     If a firewall situated at the edge of the host network cannot be
     configured to pass protocols in the IPsec suite, then some
     mechanism must be provided which converts the data stream to one



Kelly, Ramamoorthi          Expires May 2001                  [Page 27]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


     which the firewall may be configured to pass.  If the firewall can
     be configured to pass IPsec protocols, then this must be
     accomplished prior to connection establishment.



3.5 Remote Dialup Laptop (Road Warrior) Access

     This is a very common remote access scenario, and is virtually
     indistinguishable from the telecommuter scenario, except that the
     connections are typically dialup only, and hence, short-lived.

     Refer to section 3.1.1 for details.


3.6 Public System to Corporate Network

     This scenario entails a traveling user connecting to the corporate
     network using a public system owned by someone else. A commonly
     cited example is an airport kiosk. This looks very similar to the
     extranet desktop scenario, except that in the extranet scenario,
     CORP-A might have a trust relationship with CORP-B, whereas in this
     scenario, CORP-A may not trust a publically accessible system. Note
     that a trust relationship between CORP-A and the owner of the
     public system may exist, but in many cases will not.


3.6.1 Authentication Requirements

     There are two variations to this scenario. In the first, no trust
     relationship exists between the corporate network and the borrowed
     system. In the second, some trust relationship does exist. In the
     case where no trust relationship exists, machine authentication is
     out of the question, as it is meaningless in this context. Further,
     since such a system could easily capture a passphrase, use of a
     static passphrase from such a system would seem to be ill-advised.

     If a one-time passphrase were used, this would mitigate the risk of
     passphrase capture by the public system. On the other hand, if it
     is acknowledged that such capture is a real threat (i.e. the system
     itself is malicious), then it must also be recognized that any data
     transmitted and received via the resulting session would not be
     confidential with respect to this malicious system, and that the
     system could not be trusted to have actually disconnected when the
     user walks away. This suggests that accessing non-trivial
     information from such a system would be imprudent.

     Another possible user authentication option would be a smartcard.



Kelly, Ramamoorthi          Expires May 2001                  [Page 28]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


     However, many smartcards require a pin or passphrase to "unlock"
     them, which requires some level of trust in the kiosk to not record
     the pin.  Hence, this approach suffers from drawbacks similar to
     those of the static passphrase in this regard. The primary
     difference would be that the pin/passphrase could not be used alone
     for access in the smartcard case.

     In cases where a trust relationship with the owner of the public
     system exists, the trust level would modulate the risk levels
     discussed above.  For example, if a sufficient level of trust for
     the system owner exists, use of a static passphrase might present
     no more risk than if this were permitted from a system owned by the
     accessed corporation. However, the primary benefit of such a trust
     relationship would be derived from the ability to authenticate the
     machine from which the user is attempting access.  For example, a
     security policy requiring that remote access only be permitted with
     combined user/machine authentication might be effected, with
     further control regarding which machines were allowed.

     An additional issue to be dealt with in either case pertains to
     verification of the identity of the IRAS. If the IRAC were to be
     misdirected somehow, a man in the middle attack could be effected,
     with the obtained password being then used for malicious access to
     the true IRAS. Note that even a one-time password mechanism offers
     little protection in this case. In order to avert such an attack,
     the IRAC must possess some certifiable or secret knowledge of the
     IRAS prior to attempting to connect. Note that in the case where no
     trust relationship exists, this is not possible.

     To summarize, the following are the authentication requirements for
     the IRAS and IRAC:

     IRAS
     ----

     o machine authentication MUST be provided.

   IRAC
   ----

     o in cases where no trust relationship exists between the
       accessed network and the system owner, sensitive data
       SHOULD NOT be transmitted in either direction.
     o in cases where a trust relationship exists between the
       accessed network and the system owner, machine authentication
       SHOULD be supported.
     o in cases where a trust relationship exists between the
       accessed network and the system owner, a static passphrase



Kelly, Ramamoorthi          Expires May 2001                  [Page 29]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


       MAY be used in conjunction with machine-level authentication
       of the IRAC system.
     o frequent renewal of user authentication MUST occur



3.6.2 Device Configuration Requirements

     None.

3.6.3 Policy  Configuration Requirements

     None.

3.6.4 Auditing Requirements

     The auditing requirements in this scenario are the same as for the
     telecommuter scenario. Session start/end times must collected.
     Reliable derivation of session end time requires that the IRAC
     somehow periodically signify that the connection remains active.
     This is implied if the IRAS receives data from the IRAC over the
     connection, but in cases where no data is sent for some period or
     time, a signaling mechanism is required by which the IRAC indicates
     that the connection remains in use.

3.6.5 Intermediary Traversal Requirements

     If the address of the IRAC system is globally routable, and no
     intermediate devices between the IRAC and the IRAS perform NAPT
     operations on the data stream, then there are no additional
     requirements in this regard. If NAPT operations are performed on
     the data stream, some mechanism must be provided in order to render
     these modifications transparent to the IPsec implementation.


4. Scenario Commonalities

     As we examine the various remote access scenarios, a general set of
     common requirements emerge. Following is a summary:

     o Support for user authentication is required in almost
       all scenarios

     o Machine authentication for the IRAS is required in all
       scenarios

     o A mechanism for providing device configuration for the
       IRAC is required in most scenarios. Such a mechanism must



Kelly, Ramamoorthi          Expires May 2001                  [Page 30]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


       be extensible.

     o Machine authentication for IRAC is generally only useful
       when combined with user authentication. Combined user and
       and machine authentication  is useful in some scenarios.

     o Dynamic IRAC policy configuration is useful in several
       scenarios.

     o Most scenarios require auditing for session start/stop
       times.

     o An intermediary traversal mechanism may be required in
       any of the scenarios.


5. Security Considerations

   The topic of this document is secure remote access. Security
   considerations are discussed throughout the document.

6. Editors' Addresses

   Scott Kelly
   RedCreek Communications
   3900 Newpark Mall Road
   Newark, CA 94560 USA
   email: skelly@redcreek.com
   Telephone: +1 (510) 745-3969

   Sankar Ramamoorthi
   Nexsi
   1959 Concourse Drive
   San Jose, CA 95131 USA
   E-mail: sankar@nexsi.com
   Telephone: +1 (408) 579-5718


7. References

   [ARCH]      Kent, S., and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

   [KEYWORDS]  Bradner, S., "Key Words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RADIUS]    C. Rigney, A. Rubens, W. Simpson, S. Willens,
               "Remote Authentication Dial In User Service



Kelly, Ramamoorthi          Expires May 2001                  [Page 31]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


               (RADIUS)", RFC2138

   [IKE]       Harkins, D., and D. Carrel, "The Internet Key Exchange
               (IKE)", RFC 2409, November 1998.



8. Acknowledgements

   The editors would like to acknowledge the many helpful comments of Sara
   Bitan, Steve Kent, and other members of the ipsra working group who have
   made helpful comments on this work.


9. Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Appendix A: Change Log

   00 to 01:




Kelly, Ramamoorthi          Expires May 2001                  [Page 32]

Internet Draft      <draft-ietf-ipsra-reqmts-02.txt>      November, 2000


   o delete mobility requirements
   o add accounting requirements
   o extensively modify discussion of endpoint authentication, and
     machine vs. user authentication
   o delete roaming/wireless users and user-to-user connections from
     Scenarios bullet list
   o Add discussion of trojan horse applications to telecommuter scenario
   o add statement about encouraging migration to PKI-based systems to
     legacy compatibility section.
   o clarified language in section 2.3 (Security Policy Configuration)

   01 to 02:

   o add n-factor authentication to general requirements
   o change "accounting" to "auditing"
   o delete incoming/outgoing octet counts from auditing requirements
   o added intermediary traversal requirements
   o numerous general edits for clarity

































Kelly, Ramamoorthi          Expires May 2001                  [Page 33]

--------------41262999D822C0FFD5D36F1B--



From owner-ietf-ipsra@mail.vpnc.org  Tue Nov 28 23:57:21 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17301
	for <ipsra-archive@odin.ietf.org>; Tue, 28 Nov 2000 23:57:21 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23641
	for ietf-ipsra-bks; Tue, 28 Nov 2000 20:12:57 -0800 (PST)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA23634
	for <ietf-ipsra@vpnc.org>; Tue, 28 Nov 2000 20:12:54 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p0501045eb64a2fd66f20@[165.227.249.17]>
Date: Tue, 28 Nov 2000 20:14:20 -0800
To: ietf-ipsra@vpnc.org
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Agenda proposal for San Diego
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

Greetings again. We have a 2.5 hour slot (0900-1130 Tuesday) and 
plenty of things to put in it. I propose the following:

5 min   <stdwginit.h>
30 min  IPSRA requirements (draft-ietf-ipsra-reqmts-01.txt)
45 min  Configuration document (draft-ietf-ipsec-dhcp-08.txt)
45 min  Protocol documents (draft-ietf-ipsra-getcert-00.txt)
                            (draft-ietf-ipsra-pic-01.txt)
25 min  Charter revision, focus discussion

We are getting close to closure on DHCP, but we haven't come to any 
agreement on the protocol documents. We have also let other ideas 
slip away, so we need to talk about the charter and our focus.

If people have different views of what we should do here, by all 
means bring them to the list.

--Paul Hoffman, Director
--VPN Consortium


From owner-ietf-ipsra@mail.vpnc.org  Tue Nov 28 23:57:27 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17327
	for <ipsra-archive@odin.ietf.org>; Tue, 28 Nov 2000 23:57:27 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23839
	for ietf-ipsra-bks; Tue, 28 Nov 2000 20:21:50 -0800 (PST)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA23835
	for <ietf-ipsra@vpnc.org>; Tue, 28 Nov 2000 20:21:49 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p0501045fb64a34d09a7d@[165.227.249.17]>
In-Reply-To: <p0501045eb64a2fd66f20@[165.227.249.17]>
References: <p0501045eb64a2fd66f20@[165.227.249.17]>
Date: Tue, 28 Nov 2000 20:23:16 -0800
To: ietf-ipsra@vpnc.org
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: Re: Agenda proposal for San Diego
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

At 8:14 PM -0800 11/28/00, Paul Hoffman / VPNC wrote:
>30 min  IPSRA requirements (draft-ietf-ipsra-reqmts-01.txt)

Make that:
30 min  IPSRA requirements (draft-ietf-ipsra-reqmts-02.txt)

Scott posted the -02 draft to the mailing list the other day. If you 
missed it, you can see it at 
<http://www.vpnc.org/ietf-ipsra/mail-archive/msg00866.html>.

--Paul Hoffman, Director
--VPN Consortium


From owner-ietf-ipsra@mail.vpnc.org  Wed Nov 29 12:58:09 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02438
	for <ipsra-archive@odin.ietf.org>; Wed, 29 Nov 2000 12:58:08 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA25534
	for ietf-ipsra-bks; Wed, 29 Nov 2000 09:00:18 -0800 (PST)
Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA25529
	for <ietf-ipsra@vpnc.org>; Wed, 29 Nov 2000 09:00:17 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffvpnc@mail.vpnc.org
Message-Id: <p05010462b64ae4d4f548@[165.227.249.17]>
Date: Wed, 29 Nov 2000 09:01:46 -0800
To: ietf-ipsra@vpnc.org
From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
Subject: IPSRA WG LAST CALL: draft-ietf-ipsec-dhcp-08.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>

This is the beginning of a three-week WG last call on 
draft-ietf-ipsec-dhcp-08.txt. You can find a copy at 
<http://www.ietf.org/internet-drafts/draft-ietf-ipsec-dhcp-08.txt>.

This draft will be discussed in San Diego, but it would be really 
grand if everyone can look at it sooner and comment on the mailing 
list. Doing so will make the discussion in San Diego more focused, 
and allows the authors to respond to requests for changes both on the 
list and in the face-to-face meeting.

And, for those of you who are sticklers on procedure, this draft is 
not officially part of the IPSRA WG work, but it has been 
unofficially moved to us because of its content. This is a minor 
status issue and will not affect our discussion nor its eventual 
standardization status.

--Paul Hoffman, Director
--VPN Consortium


From owner-ietf-ipsra@mail.vpnc.org  Wed Nov 29 21:06:19 2000
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14352
	for <ipsra-archive@odin.ietf.org>; Wed, 29 Nov 2000 21:06:18 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id RAA21530
	for ietf-ipsra-bks; Wed, 29 Nov 2000 17:11:09 -0800 (PST)
Received: from mail2.cpip.net.cn ([210.73.64.199])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21522
	for <ietf-ipsra@vpnc.org>; Wed, 29 Nov 2000 17:11:07 -0800 (PST)
Date: Wed, 29 Nov 2000 17:11:07 -0800 (PST)
From: V@tzw.de
Message-Id: <200011300111.RAA21522@ns.secondary.com>
Received: from h809 ([63.30.194.82]) by mail2.cpip.net.cn
          (Netscape Messaging Server 3.01)  with SMTP id AMV6009;
          Thu, 30 Nov 2000 09:16:53 +0800
To: V@tzw.de
Subject: Lady V:  The Pleasure Pill for Women!
Sender: owner-ietf-ipsra@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ietf-ipsra/mail-archive/>
List-ID: <ietf-ipsra.vpnc.org>
List-Unsubscribe: <mailto:ietf-ipsra-request@vpnc.org?body=unsubscribe>


LADY V: The Pleasure Pill for Women!

Men Have Their Viagra®! Finally, A Pill for Women! 

It's Here! The Revolutionary Woman's Sexual Sensation is Now
                           Available.

Researchers are calling Lady V the greatest breakthrough
for women since the Birth Control Pill. And you don't even need
a prescription to get it!

               Welcome to the New Sexual Revolution!

It's no secret that men have been having the time of their
lives since the wonder pill Viagra® was made available. But,
women were left out in the cold with no pill... nothing! 
Well now thanks to an all-star team of medical researchers 
who have been working around the clock, those days are finally
over. The perfect female "pleasure pill" has been created and
you don't even need a prescription. You can now get it from
Lion Sciences!

Lady V is the world's first pleasure pill scientifically 
designed for women. Lady V is an all-natural proprietary 
herbal blend of prosexual nutrients from around the world
synergistically blended to naturally stimulate neurotransmitter
endorphin signals. This magical combination increases targeted
blood flow, unleashes natural stimulator for maximum stimulation,
triggering pleasure responses quickly. Lady V is safe, natural
and doctor-recommended.
Since its introduction Lady V has been taking the world by storm!
From Malibu to Miami women are enjoying the most intense pleasure
of their lives! 

• 100% Natural
• Safe
• The Highest Quality Pharmaceutical Pure Nutraceuticals
• Guaranteed Potency
• Certified Purity

                     Lady V is Sweeping the Nation!

Women are going crazy over Lady V. Suddenly couples are falling
in love all over again. The passion and pleasure that women are
reporting is off the charts! Lady V has an incredible 88% success
rate. Best of all, while Viagra costs $10 a pill, Lady V costs
less than $1 a pill! It's not just a man's world anymore!

Just look at what a few women have to say:

"I thought my love life was good before, but now it is out of
this world! Lady V is remarkable." — Mary J., Interior Designer

"I haven't smiled like this in a long time. My husband and I 
feel like a couple of 19 year olds again!" — Debra T, Assistant Buyer

"Imagine what it would feel like to have incredible passion
and pleasure anytime you want." — Jennifer C., Film Editor

"Suddenly my husband and I are spending more time in the bedroom
instead of the TV room." — Angie R., Realtor

Ingredients: Vitamin D, Niacin, Vitamin B6, Folic Acid,
Vitamin B12, Avena Sativa, Kava Kava, Guarana, White Willow Extract,
Mura Puama, St. John's Wort, Siberian Ginseng, Cordyceps, Damiana,
and L-Taurine.

Each bottle of Lady V contains 30 tablets.
Take three capsules one hour before romantic activity
as a dietary supplement. 

Risk Free: Double Your Money Back Guarantee

If Lady V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked! 

Order Now: Safe, Fast, Secure, Private

Lady V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail. 


Each bottle of Lady V contains 30 tablets.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of Lady V  $24


______ 2 Bottles of Lady V $44


______ 3 Bottles of Lady V $59


Please add $6 shipping and handling for any size order. 
[ Total cost including shipping & handling, 
1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ]

International Orders
Please add $18 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$42, 2 bottles=$62, 3 bottles=$77 ]
We cannot accept foreign checks.
International money orders or credit cards only.

Step 2: Place a check by your desired payment method 
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order 


_____American Express 
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".
 

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________ 


Address _________________________________________________


City ____________________________________________________ 


State ___________________________________________________ 


Zip _____________________________________________________ 


E-mail __________________________________________________ 


Signature _________________________________________________
[ required for check and credit card orders]



             Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all. 
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

  Or, print & mail to: LSN   
                       273 S. State Rd. 7, #193
                       Margate, FL 33068-5727               


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of 
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW















              _____________________________________________________________

This is a one time mailing: Removal is automatic and no further 
contact is necessary. Please Note: Lady V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Lady V helps provide herbal and nutritional support
for female sexual performance. The FDA has not evaluated these 
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs 
department; enclose a self addressed stamped envelope for this and any 
requested contact information.
Thank You.