Subject: RE: [Ecrit] Emergency [VPN issue]

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 14 Sep 2005 11:18:01 -0400

Brian,

The question is not "who", but "what".  The who (carrier) can be playing
a multiplicity of roles.  The issue is "what" device is closest to the
client terminal and can provide location.  The "who" is secondary.  Once
you pinpoint the access device, who operates that falls out immediately.

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Tuesday, September 13, 2005 5:32 PM
> To: Michael Hammer (mhammer); 'Rodrig, Benny (Benny)'; 
> 'Winterbottom, James'; 'ECRIT'
> Subject: RE: [Ecrit] Emergency [VPN issue]
> 
> For the purposes of this discussion, the access data 
> transport network is responsible for location.  The way I 
> look at it, it's the "last" (or "first"
> if you will) mile provider.
> 
> If the length of the network from there is big enough, you 
> need to add room level location.  From a definition 
> standpoint, it gets sticky.  What is the conceptual and 
> terminology difference from an enterprise with 3 levels of 
> Ethernet switch, two levels of routing and a VPN, and Marc 
> Linser's home with one switch, one "home router" and a VPN 
> tunnel to it.  We don't need room level location for the 
> latter, although we would welcome it.  We probably do need 
> room level location from the former.
> 
> But, who is the "access data transport" network in the former 
> case?  Is it the carrier that serves the HQ location, or the 
> enterprise itself?
> 
> Brian
> 
> -----Original Message-----
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Tuesday, September 13, 2005 5:03 PM
> To: [email-masked]; Rodrig, Benny (Benny); Winterbottom, 
> James; ECRIT
> Subject: RE: [Ecrit] Emergency [VPN issue]
> 
> I think this terminology issue has been bounced around the 
> ITU-T FGNGN quite a bit.  I had thought that the discussion 
> was starting to converge on the idea that there were access 
> data transport (IP) networks and core data transport (IP) 
> networks.  All the hosts that sit on those networks, such as 
> voice servers, should focus on using other terms, such as 
> originating and terminating to describe their relationship to 
> the user.
> Using "access" for a host far removed from the point where 
> the user accesses the data network is both counter-intuitive 
> and misleading.
> Better to keep the data and application related adjectives 
> independent.
> 
> my 2 cents,
> Mike
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Brian Rosen
> > Sent: Tuesday, September 13, 2005 7:08 AM
> > To: 'Rodrig, Benny (Benny)'; 'Winterbottom, James'; 'ECRIT'
> > Subject: RE: [Ecrit] Emergency [VPN issue]
> > 
> > Benny
> > 
> > There are some authentication issues with who is the source of 
> > location information, but in general, I believe the 
> enterprise IS the 
> > access provider, it simply has an upstream access provider to it.  
> > This is not unlike a tier 2 or tier 3 ISP.  The point is that if an 
> > enterprise is large enough, we need it to supply room-level 
> location, 
> > and the access network to it cannot do that.  In very large 
> > enterprises, the access provider may only be at the headquarters 
> > location; remote sites may be served by private networks.  In such 
> > cases we are wholly reliant on the enterprise to provide accurate 
> > location.
> > 
> > Brian
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Rodrig, Benny (Benny)
> > Sent: Monday, September 12, 2005 9:54 AM
> > To: Winterbottom, James; ECRIT
> > Subject: RE: [Ecrit] Emergency [VPN issue]
> > 
> > James,
> > 
> > I don't see how the enterprise, even with a VPN policy, can be 
> > considered an access provider. The concept of the access 
> provider, as 
> > opposed to the application service provider, implies some sort of 
> > locality and hence knowledge of user's location. These do not shift 
> > from the local Internet access provider to the remote enterprise 
> > headquarters just because the endpoint is connecting through a VPN.
> > 
> > Benny
> > 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Winterbottom, James
> > Sent: Sunday, September 11, 2005 7:13 PM
> > To: James M. Polk; ECRIT
> > Subject: RE: [Ecrit] Emergency [VPN issue]
> > 
> > Hi James,
> > 
> > Actually that is not really the point that I am making. The point I 
> > was making was that if the enterprise forces its remote 
> staff to pass 
> > all traffic through the VPN, including emergency calls, then the 
> > enterprise is, for all intents and purposes the access 
> provider, and 
> > is responsible to ensure that the call will get to where it 
> needs to 
> > go.
> > 
> > On the technology front I don't see why a solution shouldn't be 
> > universal either. Change to soft-phones in firmware or software are 
> > going to be required to get location, and if I understand 
> the proposed 
> > solutions correctly then, determine that the call is an 
> emergency one 
> > and provide location also.
> > So I don't see that providing split tunneling to cater for this is 
> > such a big deal. If enterprises elect not to deploy or engage this 
> > functionality then the point of responsibility is clear.
> > 
> > Cheers
> > James
> > 
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[email-masked]]
> > > Sent: Monday, 12 September 2005 8:44 AM
> > > To: Winterbottom, James; Michael Hammer (mhammer); 
> Stastny Richard;
> > Marc
> > > Linsner (mlinsner); ECRIT
> > > Subject: RE: [Ecrit] Emergency [VPN issue]
> > > 
> > > James
> > > 
> > > I don't understand the point you're making here.
> > > 
> > > Are you suggesting NENA believes a VPNd phone should not 
> communicate
> > over
> > > the VPN when calling <sos> ?
> > > 
> > > I don't believe this will be universally available
> > > 
> > > At 06:29 PM 9/8/2005 -0500, Winterbottom, James wrote:
> > > >This issue has been discussed in NENA at quite some length. The 
> > > >consensus that is growing there, and I know that there are some
> > people
> > > >that still disagree, is that if an enterprise is 
> prepared to allow
> > this
> > > >to occur, that the onus is on the enterprise to ensure
> > that it works.
> > > >This makes the problem a little easier to deal with.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf
> > > >Of
> > > > > Rodrig, Benny (Benny)
> > > > > Sent: Friday, 9 September 2005 9:14 AM
> > > > > To: Michael Hammer (mhammer); Stastny Richard; Marc Linsner
> > > >(mlinsner);
> > > > > ECRIT
> > > > > Subject: RE: [Ecrit]
> > EmergencyContextRoutingofInternetTechnologies-
> > > > > ArchitectureConsiderations
> > > > >
> > > > > Not sure it's always possible for emergency calls to
> > not go though
> > the
> > > > > corporate VPN. For example, the endpoint may have no 
> means (e.g.
> > no
> > > >TURN
> > > > > server) to establish a session directly through the NAT at the
> > > >Backwater
> > > > > Inn, in the example below.
> > > > >
> > > > > Benny
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: [email-masked] 
> [mailto:[email-masked]] On
> > Behalf
> > > > > Of Michael Hammer (mhammer)
> > > > > Sent: Thursday, September 08, 2005 6:26 PM
> > > > > To: Stastny Richard; Marc Linsner (mlinsner); ECRIT
> > > > > Subject: RE: [Ecrit]
> > > > > EmergencyContextRoutingofInternetTechnologies-Architecture
> > > > > Considerations
> > > > >
> > > > > Richard,
> > > > >
> > > > > My original question was about whether a PSAP should
> > expect calls
> > > > > (signaling and media) to originate from non-local 
> destinations,
> > e.g.
> > > > > international, and by inference the need for the PSAPs
> > to be able
> > to
> > > > > make call backs to those locations.  If not, then
> > perhaps it is a
> > DDoS
> > > > > clue.
> > > > >
> > > > > Marc pointed out the VPN possibility.
> > > > >
> > > > > You seem to suggest that emergency calls should never 
> go by VPN
> > when
> > > > > dialed.
> > > > >
> > > > > So, is the VPN situation a possibility or precluded?
> > > > >
> > > > > Mike
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stastny Richard [mailto:[email-masked]]
> > > > > > Sent: Thursday, September 08, 2005 5:58 PM
> > > > > > To: Michael Hammer (mhammer); Marc Linsner (mlinsner); ECRIT
> > > > > > Subject: Re: [Ecrit] Emergency 
> > > > > > ContextRoutingofInternetTechnologies-Architecture
> > Considerations
> > > > > >
> > > > > > Sorry, but I am confused with this examples:
> > > > > >
> > > > > > Somebody sitting say in Chicago should get routed to a local
> > PSAP in
> > > > > > Chicago, regardless where his provider or sip-server
> > is located
> > > > > >
> > > > > > If he is using a VPN to say a network in Berlin, he 
> may either
> > also
> > > > > > get routed by some magic we still have to work out also to a
> > PSAP in
> > > > > > Chicago, or he is routed wrongly to a PSAP in Berlin.
> > > > > >
> > > > > > But, the PSAP in Berlin will at least get some
> > location and also
> > > >some
> > > > > > identification from Berlin, at the network, so there is some
> > local
> > > > > > relationship
> > > > > >
> > > > > > So what is the point?
> > > > > >
> > > > > > -richard
> > > > > >
> > > > > > ________________________________
> > > > > >
> > > > > > Von: [email-masked] im Auftrag von Michael Hammer
> > (mhammer)
> > > > > > Gesendet: Do 08.09.2005 22:56
> > > > > > An: Marc Linsner (mlinsner); ECRIT
> > > > > > Betreff: RE: [Ecrit] Emergency 
> > > > > > ContextRoutingofInternetTechnologies-Architecture
> > Considerations
> > > > > >
> > > > > >
> > > > > >
> > > > > > That is certainly possible.  I'm trying to get an 
> idea of the
> > > >assumed
> > > > > > topology models here.  If the call gets dropped, 
> does the PSAP
> > make
> > > >an
> > > > >
> > > > > > "international call" to call back such subscribers? 
>  Could the
> > call
> > > > > > back number be a number in some Caribbean island that
> > happens to
> > be
> > > >a
> > > > > > 9xx equivalent?  Could Berlin Ind. send a 3xx 
> response and say
> > drop
> > > > > > out of this VPN to make the call?
> > > > > >
> > > > > > In any case, your example proves the exception, so 
> likely mine
> > was a
> > > > > > dead end thought.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Marc Linsner (mlinsner)
> > > > > > > Sent: Thursday, September 08, 2005 4:18 PM
> > > > > > > To: Michael Hammer (mhammer); 'ECRIT'
> > > > > > > Subject: RE: [Ecrit] Emergency Context 
> > > > > > > RoutingofInternetTechnologies-Architecture Considerations
> > > > > > >
> > > > > > > How about an employee of Berlin Industries, Inc. 
> sitting at
> > the
> > > > > > > Backwater Inn with a full vpn up to their corp. hq
> > and calling
> > for
> > > > > > > help.  Wouldn't they look like they were coming 
> from Berlin
> > > > > > (the .ru
> > > > > > > domain and IP address would probably be a hint)?  Do you
> > > > > > want to block
> > > > > > > them?
> > > > > > >
> > > > > > > I certainly think that it is reasonable to raise a
> > flag to the
> > 
> > > > > > > calltaker in this situation, but I wouldn't think you want
> > > > > > to build a
> > > > > > > state machine to simply block such calls.
> > > > > > >
> > > > > > > Replace Berlin with New Hampshire, New York, Mass........
> > > > > > >
> > > > > > > -Marc-
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: [email-masked]
> > > > > > > [mailto:[email-masked]] On Behalf
> > > > > > > > Of Michael Hammer (mhammer)
> > > > > > > > Sent: Thursday, September 08, 2005 3:12 PM
> > > > > > > > To: Ted Hardie; [email-masked];
> > > > > > > [email-masked]; Andrew
> > > > > > > > Newton; Stastny Richard; ECRIT
> > > > > > > > Subject: RE: [Ecrit] Emergency Context 
> > > > > > > > RoutingofInternetTechnologies-Architecture 
> Considerations
> > > > > > > >
> > > > > > > > Ted,
> > > > > > > >
> > > > > > > > I'm confused.  Are calls from Asia or Europe to
> > the Vermont
> > > > > > > PSAP ever
> > > > > > > > legitimate?
> > > > > > > >
> > > > > > > > Somehow, I can't picture the local sheriff being able to
> > > > > > > help someone
> > > > > > > > in Berlin.  I thought the point of i3 is to
> > enable the call
> > > > > > > to go to
> > > > > > > > the local Berlin Polizei.  Put another way, is 
> it possible
> > > > > > > to use the
> > > > > > > > local nature of emergency service to protect 
> agains DDoS?
> > > > > > > >
> > > > > > > > Mike
> > > > > > > >
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: [email-masked]
> > > > > > > > [mailto:[email-masked]] On Behalf
> > > > > > > > > Of Ted Hardie
> > > > > > > > > Sent: Thursday, September 08, 2005 1:55 PM
> > > > > > > > > To: [email-masked]; [email-masked];
> > > > > > > Andrew Newton;
> > > > > > > > > Stastny Richard; ECRIT
> > > > > > > > > Subject: RE: [Ecrit] Emergency Context Routing 
> > > > > > > > > ofInternetTechnologies-Architecture Considerations
> > > > > > > > >
> > > > > > > > > After reading the thread, I wanted to come back
> > to Nate's
> > > > > > > original
> > > > > > > > > concern and call something out:
> > > > > > > > >
> > > > > > > > > >Here is the PSAP concern:
> > > > > > > > > >
> > > > > > > > > >An enterprising thief could figure out that 
> a business
> > > > > > > (without an
> > > > > > > > > >alarm
> > > > > > > > > >system) in Backwater, Vermont is served by a
> > PSAP located
> > 25
> > > > > > > > > miles away.
> > > > > > > > > >If one creates an IP-based denial of service 
> attack on
> > that
> > > > > > > > > PSAP then
> > > > > > > > > >it is safe to assume that the target of
> > opportunity that
> > the
> > > > > > > > > thief is
> > > > > > > > > >looking at in Backwater will not be able to 
> contact the
> > PSAP
> > > > > > > > > to summon
> > > > > > > > > >help.
> > > > > > > > >
> > > > > > > > > I'm assuming that the PSAP being 25 miles away means
> > > > > > > nothing about
> > > > > > > > > where the responders are.  The responders in this
> > > > > > > instance might be
> > > > > > > > > sheriffs, for example, who are stationed nearby, even
> > > > > > > > further than 25
> > > > > > > > > miles away, or whose patrol routes mean that their
> > distance
> > > > > > > > from the
> > > > > > > > > target of opportunity is variable.  So I think we
> > > > > > should cut the
> > > > > > > > > distance from this description completely, and
> > simply see
> > > > > > > > the threat
> > > > > > > > > as "If the bad actor can determine which PSAP 
> serves an
> > > > > > > > area in which
> > > > > > > > > a target is present, a successful attack on the PSAP
> > prevents
> > > > > > > > > responses to the target".
> > > > > > > > >
> > > > > > > > > Does that make sense?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Using PSTN technologies, an enterprising thief could
> > create
> > > > > > > > > a PSTN DoS
> > > > > > > > > >on the PSAP by simply using an auto call
> > generator from a
> > > > > > > > pay phone
> > > > > > > > > >located in the same proximity as the target of
> > opportunity
> > > > > > > > however,
> > > > > > > > > >this would still create a response to the
> > general area of
> > > > > > > > the crime.
> > > > > > > > >
> > > > > > > > > There are lots of other kinds of PSTN attacks 
> here--the
> > > > > > > > most commonly
> > > > > > > > > portrayed being "cutting the line", which doesn't work
> > > > > > > quite as it
> > > > > > > > > seems in the movies, but does have some effect.
> > > > > > > > >
> > > > > > > > > To avoid the locality problem in this attack, the bad
> > actor
> > > > > > > > can use an
> > > > > > > > > accomplice, meat or mechanical, in any other 
> area served
> > by
> > > > > > > > the PSAP
> > > > > > > > > to do the same thing.  This avoids the 
> response hitting
> > > > > > > the general
> > > > > > > > > area of the crime.  It also has the same
> > counter-measure;
> > > > > > > > > call-blocking of the attacking phone.  This
> > counter-measure
> > > > > > > > is  also
> > > > > > > > > relatively easy to accomplish with an 
> IP-based service,
> > > > > > > > provided the
> > > > > > > > > attack is coming from a single IP or block. I
> > believe the
> > > > > > > > problem is
> > > > > > > > > harder in the IP case not because the area from
> > which the
> > > > > > > > attack can
> > > > > > > > > originate is larger but because it is easier 
> to create a
> > > > > > > > Distributed
> > > > > > > > > Denial of Service, largely because of zombie
> > networks and
> > > > > > > > IP spoofing.
> > > > > > > > > That is, if the attack is coming from Europe while the
> > > > > > attack is
> > > > > > > > > happening on Backwater, my response is the 
> same as if it
> > > > > > > came from
> > > > > > > > > Nearwater, VT:
> > > > > > > > > block the attack source.  But if it is coming from
> > > > > > Europe, Asia,
> > > > > > > > > Nearwater, Backwater, and many other points as well,
> > > > > > > > attempts to block
> > > > > > > > > the attack either requires effectively severing
> > connectivity
> > > >or
> > > > > > > > > maintaining a fair amount of information about
> > who at the
> > > > > > > IP layer
> > > > > > > > > should be talking to this PSAP.  We've discussed the
> > > > > > > > effectiveness of
> > > > > > > > > that in the past.
> > > > > > > > >
> > > > > > > > > >If I
> > > > > > > > > >know the URI of the PSAP, I can now distract it from
> > another
> > > > > > > > > continent
> > > > > > > > > >and do what I would need to do in Backwater and no
> > > > > > > > response would be
> > > > > > > > > >created in that direction - that is the new
> > paradigm with
> > > > > > > > > IP. If I know
> > > > > > > > > >the boundaries of the Derby PSAP, I could 
> create a PSTN
> > > > > > > based DoS
> > > > > > > > > >attack anywhere from within that boundary
> > (potentially 50
> > > > > > > > miles from
> > > > > > > > > >Island Pond).
> > > > > > > > > >
> > > > > > > > > >Would this happen? I don't know - I am pretty sure it
> > > > > > > > hasn't yet but
> > > > > > > > > >assigning a URI to a PSAP opens it up to whole new
> > > > > > generation of
> > > > > > > > > >"creative thinkers".....
> > > > > > > > > >
> > > > > > > > > >Of course we can minimize the impact on the PSAP at a
> > > > > > > higher level
> > > > > > > > > >gateway by throwing a huge amount of bandwidth
> > at it and
> > > > > > > > building in
> > > > > > > > > >intelligent alternative routing on a robust
> > firewall. But
> > > > > > > > > that does not
> > > > > > > > > >help in the interim between here and there 
> when someone
> > > > > > > gets their
> > > > > > > > > >hands on the PSAP boundaries and realizes the attacks
> > they
> > > > > > > > > can initiate
> > > > > > > > > >using the PSTN DoS approach.
> > > > > > > > >
> > > > > > > > > The problem with the proposed solution, I
> > believe, is that
> > > > > > > > aggregating
> > > > > > > > > the access to a back-to-back user agent or all-knowing
> > > > > > > > gateway is that
> > > > > > > > > you have simply created a richer target for
> > attack.  If I
> > > > > > > > can marshal
> > > > > > > > > a zombie group that takes out all of 
> Vermont's PSAPs by
> > > > > > > eliminating
> > > > > > > > > the the gateway by DDoS, I have done far 
> worse far more
> > > > > > > > easily than I
> > > > > > > > > could by individually attacking the PSAPs at 
> their URIs.
> > > > > > > > If I did it
> > > > > > > > > in order to get at Backwater's target, I likely don't
> > > > > > > care that the
> > > > > > > > > general effect is larger--my purpose is met.
> > > > > > > > >
> > > > > > > > > Yes, it is easier to escalate the defenses at a single
> > > > > > > > point and yes,
> > > > > > > > > it is easier to pay for  fat pipes for that
> > single point.
> > > > > > > > But the bad
> > > > > > > > > actors here aren't using their own resources to attack
> > you;
> > > > > > > > they are
> > > > > > > > > stealing them before trying to steal from 
> you.  Getting
> > > > > > > > into an arms
> > > > > > > > > race with someone who isn't spending their own money
> > worries
> > > >me.
> > > > > > > > >
> > > > > > > > >                   regards,
> > > > > > > > >                           Ted
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Ecrit mailing list
> > > > > > > > > [email-masked]
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Ecrit mailing list
> > > > > > > > [email-masked]
> > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Ecrit mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Ecrit mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > >
> > >-------------------------------------------------------------
> > ----------
> > --
> > > -----------------------
> > > >This message is for the designated recipient only and 
> may contain 
> > > >privileged, proprietary, or otherwise private information.
> > > >If you have received it in error, please notify the sender 
> > > >immediately and delete the original.  Any unauthorized 
> use of this 
> > > >email is prohibited.
> > >
> > >-------------------------------------------------------------
> > ----------
> > --
> > > -----------------------
> > > >[mf2]
> > > >
> > > >_______________________________________________
> > > >Ecrit mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/ecrit
> > > 
> > > 
> > > cheers,
> > > James
> > > 
> > >                                  *******************
> > >                  Truth is not to be argued... it is to be 
> presented.
> > 
> > --------------------------------------------------------------
> > ----------
> > ------------------------
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender 
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> > --------------------------------------------------------------
> > ----------
> > ------------------------
> > [mf2]
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> > 
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> > 
> > 
> > 
> > _______________________________________________
> > Ecrit mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ecrit
> > 
> 

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Sep 2005 11:35:12 -0400

Okay, then:

You look at the length of the "loop" (wire or radio).  Starting at the end
device, you look for the first one longer than some threshold.  It's circa
several thousand feet.  The device on the far (with respect to the endpoint)
device is responsible for location, unless the device contains some kind of
measurement capability (GPS, triangulation,....) in which case it's the
device who is responsible, OR there is some other measurement mechanism that
the device does not control, in which case it's the device that does the
mechanism which is responsible.

How is that?

Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 11:18 AM
To: [email-masked]; Rodrig, Benny (Benny); Winterbottom, James; ECRIT
Subject: RE: [Ecrit] Emergency [VPN issue]

Brian,

Mike