Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt

From: John LaCour <[email-masked]>
Date: Fri, 14 Sep 2001 10:38:49 -0700

You can't just say 'allow src=IP-A dst=IP-B'.  A packet
with the source address in the header = 'IP-A' could arrive
on any interface and you probably only want to allow it to be
allowed through in only one direction.  So you still need to 
communicate direction and security realms in some manner.

If you wanted to use MIDCOM to install anti-spoofing packet filtering
rules how would you do that?  Those rules typically contradict
routing and interface configurations.

I think the ability to specify explictly two realms and a vector
between them is critical.

-John

> -----Original Message-----
> From: Adina Simu [mailto:[email-masked]]
> Sent: Friday, September 14, 2001 10:28 AM
> To: John LaCour
> Cc: 'Christian Huitema'; Mark Duffy; Scott Brim; [email-masked]
> Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt
> 
> 
> John LaCour wrote:
> > 
> > We call it 'transparent' mode when our box works this way.  Its
> > essentially a bridge with stateful packet filtering and other
> > middlebox services but no routing or NAT.
> 
> If there's no NAT, then I think there's no topology problem... Am I
> missing something?
> 
> Thanks
> -Adina
> 
> > 
> > -John
> > 
> > > -----Original Message-----
> > > From: Christian Huitema [mailto:[email-masked]]
> > > Sent: Friday, September 14, 2001 9:41 AM
> > > To: Mark Duffy; Adina Simu
> > > Cc: Scott Brim; [email-masked]
> > > Subject: RE: [midcom] draft-brim-midcom-inandout-00.txt
> > >
> > >
> > > > I meant "forward the packet".  I am talking about a 
> middlebox with
> > > > exactly
> > > > 2 interfaces that has no idea what IP addresses are 
> "inside" or what
> > > > addresses are "outside".  It has no knowledge of 
> topology or routing
> > > > information except that one of the interfaces connects to
> > > "inside" and
> > > > the
> > > > other to "outside".  Packets received by it are processed for
> > > > middlebox
> > > > services then (assuming not dropped by the middlebox) 
> transmitted on
> > > > whichever of its 2 interfaces the packet was not received on.  I
> > > > believe
> > > > there are middleboxes of this sort.  I  believe such a
> > > middlebox would
> > > > be
> > > > incapable of implementing your draft since it could not 
> determine by
> > > > examining target or informant addresses whether they
> > > resided inside or
> > > > outside.
> > >
> > > I don't know of such things, and I don't believe we have to
> > > support them
> > > anyhow. Let's keep some focus: our primary concern is NAT and
> > > firewalls,
> > > and then boxes that look them. We do not have a 
> requirement to enable
> > > any wacko box that someone may invent.
> > >
> > > -- Christian Huitema
> 
> -- 
> Adina Simu
> Software Engineer
> Core IP Eng - Services & Security
> IOS Technologies Division
> Phone: 408-525-1383
> 

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: Adina Simu <[email-masked]>
Date: Fri, 14 Sep 2001 10:53:32 -0700

> between them is critical.

I see your point... we agree that the realms have to be specified... but
you're saying that specifiying them by using IP addresses is not good
enough for a FW... Let me think about it for a while.

-Adina