Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 4 Apr 2002 17:46:21 -0600

Jiri, 
  Why wouldn't a network/firewall administration application be able to use
the same Midcom protocol for opening/closing firewall pinholes? Nothing in
the charter says that this out of scope. 

Also, what you're suggesting may be too retrictive. I can't possibly assume
that all NAT's & firewalls will be Midcom-enabled at the same time. So there
might be a situation where a Midcom agent would like to open pinhole in a
firewall which is sandwitched between two NAT's which are not Midcom-aware.
The Agent doesn't have any idea about the exact NAT binds that will be used
on both sides of the FW but knows about the range of possible binds.
There'll be overlap in this case between rulesets of agents controlling the
firewall.

Sanjoy

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 5:04 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH];
> [email-masked]
> Cc: Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content
> 
> 
> At 12:27 AM 4/5/2002, Sanjoy Sen wrote:
> >How will then the following requirement from Midcom 
> requirements draft be satisfied? 
> 
> Perhaps by reading "should" as "there may exist valid reasons 
> in particular 
> circumstances to ignore a particular item, but the full 
> implications must 
> be understood and carefully weighed before choosing a 
> different course."
> (RFC2119).
> 
> >***** 
> >2.2.11. 
> >
> >     It should be possible to define rulesets that contain a 
> more spe- 
> >     cific filter spec than an overlapping ruleset.  This 
> should allow 
> >     agents to request actions for the subset that 
> contradict those of 
> >     the overlapping set. 
> >***** 
> >
> >Whether you want it or not, there would be overlapping 
> rulesets because the filterspec may overlap for different 
> rulesets installed by independent agents. 
> 
> Why? Again, thats a matter of protocol scope. If we define 
> MidCom to be
> firewall/NAT opener, then overlaps are errors and can be as 
> such denied.
> If we define it as a management protocol, things are different -- but
> MidCom is not a management protocol. Whereas some people may like
> extending its scope, I am in favor of keeping things very simple.
> 
> -Jiri
> 
>

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 05 Apr 2002 13:28:24 +0200

Sanjoy,

--On 04 April 2002 17:46 -0600 Sanjoy Sen wrote:

>
> Jiri,
>   Why wouldn't a network/firewall administration application be
> able to use the same Midcom protocol for opening/closing firewall
> pinholes? Nothing in the charter says that this out of scope.

Yes, we can do a lot more. But how much is enough? We also should
care about size and complexity and priorities of problems to be
solved.

In my view the high priority is giving applications/users the
ability to control a part of the firewall/NAT in order to enable
applications, such as NetMeeting, SIP/H323 telephony, ... to work
when middleboxes are in between.

The charter allows us to build a remote management protocol
for FWs/NATs, but I would prefer to leave this tasks to the
operations and management area.

>
> Also, what you're suggesting may be too retrictive. I can't
> possibly assume that all NAT's & firewalls will be Midcom-enabled
> at the same time. So there might be a situation where a Midcom
> agent would like to open pinhole in a firewall which is
> sandwitched between two NAT's which are not Midcom-aware. The
> Agent doesn't have any idea about the exact NAT binds that
> will be used on both sides of the FW but knows about the range
> of possible binds. There'll be overlap in this case between
> rulesets of agents controlling the firewall.

The scenario is well constructed to show that there there is
a need AT ALL to care about this. But shoudn't we just say that
the midcom protocol does not helpin this situation?

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

>> extending its scope, I am in favor of keeping things very simple.

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

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 05 Apr 2002 17:04:38 +0200

Sanjoy Sen wrote:

> Jiri,
>   Why wouldn't a network/firewall administration application be able to 
> use the same Midcom protocol for opening/closing firewall pinholes? 
> Nothing in the charter says that this out of scope.

Hmm, I'm thinking about all the different firewalls/NATs from different 
vendors, with different capabilities. We can spend years of defining 
such a management protocol, but we need a simple protocol for 
configuring holes/bindings for a defined period of time.

> 
> Also, what you're suggesting may be too retrictive. I can't possibly 
> assume that all NAT's & firewalls will be Midcom-enabled at the same 
> time. So there might be a situation where a Midcom agent would like to 
> open pinhole in a firewall which is sandwitched between two NAT's which 
> are not Midcom-aware. The Agent doesn't have any idea about the exact 
> NAT binds that will be used on both sides of the FW but knows about the 
> range of possible binds. There'll be overlap in this case between 

How does the agent know about the NATs? I thought middle box discovery 
is out of scope?

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de