Subject: RE: [midcom] requirements-01 status

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Thu, 28 Jun 2001 15:03:49 -0600

If interface specification did become a legitimate part of midcom, how
would an interface be specified? By some number? By some string? Would
this be something of a shared understanding between the middlebox and
the agent? Wouldn't this make agent (and middlebox) configuration more
complex?

Even though I see some value in interface specification, I still think
it creates at least as many problems as it solves. There are better ways
of providing topology information to a middlebox, and why make the
application agent have to worry about this? That's a really hard sell.

Does a good protocol exist for providing topology information to
middleboxes and other perimeter devices? If midcom is not the place for
this (and I don't think it is), then what would be used for this?
Snooping routing protocols? I don't see a clean answer here, either...

--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Thursday, June 28, 2001 2:42 PM
To: Bob Penfield
Cc: Melinda Shore; [email-masked]
Subject: Re: [midcom] requirements-01 status

On 28 Jun 2001 at 14:18 -0400, Bob Penfield apparently wrote:
> From: "Melinda Shore" <[email-masked]>
> <snip>
> > Please - when advocating for something funky, 1) provide a use
> > case, 2) let us know what other possible solutions were considered
> > and rejected, and 3) why you think that your suggestion is the
> > preferred one.
> 
> OK, here goes.

It looks to me like those saying interface specification is not
necessary are assuming other functions in the middlebox which might not
be there.

These test cases are pretty interesting.  In the first case you have a
pure firewall.  It does no routing, it does not even need to be
configured to know what prefixes are reachable on what interface.  I
could pick this up at the supermarket, plug it in, and it would work.
Its only rule is "if it comes in here, check what's allowed, if it's
allowed send it out there".  Since it knows nothing except its allowed
pinholes, interface information seems necessary.  The second case is
more elaborate but again, the key is that the box can do its job with a
lot less software (money), if it has information about allowed
interfaces in the pinholes.

...Scott

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

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 28 Jun 2001 17:49:08 -0400

> the agent? Wouldn't this make agent (and middlebox) configuration more

It could be as simple as using the domain names of the networks. I don't
think the configuration is all that complex. In the middlebox you just need
to label each interface with the domain name it is connected to. In the
agent, the label would be associated with the signalling proxies.

Say I have a network "mydomain.com" and you have a network "yourdomain.com"
and we want to exchange SIP traffic and have a middlebox at the peering
point to do the filtering. There will likely be a SIP proxy in my network
and a SIP proxy in your network that will handle the SIP signalling for
sessions that go across the peering point. These proxies know about each
other and probably have a secure connection (e.g. TLS) between them.
Whichever proxy performs the role of MIDCOM agent will know that the 2 sides
of the middlebox are "mydomain.com" and "yourdomain.com". The middlebox has
the interfaces labeled with "mydomain.com" and "yourdomain.com" so it can
make the proper pin-holes.

> application agent have to worry about this? That's a really hard sell.

I think this kind of information would be statically configured in the
middlebox and the agent. There is no need to exchange this information in
any protocol.