Re: Sources for Extranet Designs?

[George Capehart <capegeo () opengroup org>]

On Monday 23 February 2004 02:16 pm, Baumann, Sean C. wrote:
> > From: Wes Noonan [mailto:mailinglists () wjnconsulting com]
> >
> > Never grant access to your production network or resources

<snip>

> So I guess my specific questions are:
>
> 1.) If you say you should never allow access to resources on your
> protected or internal network, how do you handle giving access to
> services that reside on machines that cannot be duplicated (i.e.
> expensive mainframes)?

In the financial services world, this is typically handled by passing 
messages between gateway machines that live in the DMZs of the 
respective partners.  Basically, the protocol is message based.  Data 
sources and data sinks are buried way down in the soft chewy inside.  
The data sink at CorpA builds a request message that is relayed through 
a gateway machine in CorpA's B2B DMZ to CorpB's gateway machine in 
CorpB's DMZ.  This machine then relays the message on into the data 
source machine down in the soft and chewy insides of CorpB.  A service 
in CorpB's internal network parses the message, does its magic and then 
builds a reply message which then takes the same logical trip back.  In 
serious situations, the gateway systems also function as 
application-level firewalls which inspect the message content, check 
signatures, log transits, etc.  Typically, there is some NATting going 
on at the firewalls, so destination addresses are in CorpA and CorpB 
public address spaces, but they get translated into RFC1918 addresses 
at the DMZ.  With respect to direct access to services/transactsions, 
it would be more likely to find fossil remains of hens' teeth than it 
would be to find an instance of a third party having direct access to 
an internal transaction . . .
 
> 2.) Do most companies require routable address on their extranet?
> Currently we use RFC1918 address for our extranet, but we see that
> this will become a problem in the future as we add partners.

See above.

HTH,

George Capehart
-- 
George Capehart

capegeo at opengroup dot org

PGP Key ID: 0x63F0F642 available on most public key servers

"It is always possible to agglutenate multiple separate problems into a
 single complex interdependent solution.  In most cases this is a bad
 idea."  -- RFC 1925

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards