RE: [BEHAVE] RE: Firewall control

["Dan Wing" <dwing@cisco.com>]

>  > <Hannes.Tschofenig@gmx.net> wrote:
>  > > Another one would be: "Why do the IPv4 solutions don't 
>  > work given that they
>  > > are designed with extensibility in mind?"
>  > 
>  > The only work I saw the Soliman draft reference was NSIS, which
>  > uses a different signaling model.  There's been a lot more work
>  > done closer to the client-server model, which is what they're
>  > proposing also, and I gather that they're not familiar with it.
> 
> => I would appreciate a link to something that I can read 
> about similar proposals in this area. I'm aware of James' work 
> and probably should have added it to the references but 
> unintentionally didn't. 

draft-eggert-middlebox-control-survey-01.txt surveys most of
the efforts around NAT (and firewall) control including NAT-PMP,
NSIS NATFW NSLP, UPnP IGD, and James Woodyatt's ALD.  There are
placeholders for MIDCOM, RSIP, STUN Control, NLS, AFWC, and 
RSIP.

>  > I think that you're closer to right about what the real question
>  > is.  Nearly any solution to any problem introduces new problems,
>  > and I think in general the new problems introduced by both path-
>  > coupled and path-decoupled middlebox signaling are sufficiently
>  > intractible that we either end up resisting doing them at all or
>  > choose instead to go with a bunch of hacked-up messy stuff that's
>  > very situational.  
> 
> => I find it difficult to discuss a wide range of problems in 
> different deployments on such generic level. Of course every 
> solution introduces new problems but that is never a reason to 
> dismiss a solution IMHO.  There is also a wide range of 
> firewall deployment scenarios as you know and while I
> can think of some that don't need this approach, others 
> definitely do. 
> 
> So I agree with one aspect of Hannes question, which is: what was the
> problem with other proposals.  Lets discuss that.

draft-eggert-middlebox-control-survey-01.txt describes them, but
doesn't get into what's wrong with them.  The original SAFE BoF 
request hits on a few things that are wrong (an updated description
of the SAFE BoF will be available shortly, but here was the earlier
version):
  http://www.employees.org/safe/bof-request.html

Some of those might be applicable to v6 incarnations of those
protocols, too; I haven't thought about that aspect enough to
comment intelligently.

-d


> The first part of the
> question is not really useful because it doesn't tell us what those
> solutions are that we're supposed to compare with. 
> 
> Hesham
> 
>  > 
>  > I realize that the IETF doesn't do architecture but it seems to
>  > me that somehow this bigger question needs to be handled before
>  > putting effort into a different version of the same old thing.
>  > 
>  > Melinda
>  >