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

From: "Christian Huitema" <[email-masked]>
Date: Wed, 19 Sep 2001 16:21:17 -0700

> In order to associate a default interface with a middlebox (or an only
> interface), the middlebox still needs a way to specify that interface.
> How would the middlebox get the information it needs to do that?

I did not say that the default is associated with a middlebox; I said it
should be defined for an association. This can be done in many ways. For
example, in many cases the FCP will be used by a server or a peer that
is already inside a "protected domain." In that case, the default
interface is the one between the protected domain and the middlebox;
naming can be implicit. I understand that there are "softswitch"
applications that would want to control specific interfaces within a
multi-interface box. These applications will probably have a somewhat
intimate knowledge of the middlebox configuration, and resort to
explicit naming of the interfaces.
-- Christian Huitema

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

---

From: Adina Simu <[email-masked]>
Date: Wed, 19 Sep 2001 18:15:25 -0700

> explicit naming of the interfaces.

If:
- the agent uses the right informant address
- the middlebox does IP routing (which should be the case if multiple
interfaces are present)

then the middlebox can infer the interfaces from the informant
addresses.

The security is okay as long as the informant address is a valid one.

If that's not secure, and somebody tricks the agent into asking for
pinholes to be opened... this is a different issue... Also, if the agent
doesn't specify both ingress/egress realms, then the middlebox might
open too much. I'm not sure the outside_okay flag is enough, from this
perspective. 
On some FWs, there's no notion of "Inside" and "Outside". There are
access lists and inspection
rules applied to interfaces. Plus, in reality there are different
degrees of "Inside/Outside". 

One possible example is: an enterprise FW with multiple interfaces,
connecting several Depts, the DMZ and the Internet:

                      Internet
                         |
Dept.A                 e2|                Dept.B
                      --------
endp1  10.0.0.1-|   e1|      |e3   |-3.3.3.1 endp2
                |-----|      |-----|
                      |      |
                      |      |e4
                      |      |-----|      Dept.C
                      --------     |-7.7.7.1 endp3
                         |e5
                         |
                        ---- DMZ
                          |
                        5.5.5.1
                        SIP Proxy + registrar + agent

I assume that all call signalling goes through the Proxy.

When endp1 registers with the Proxy, no midcom interaction is needed.
When somebody wants to call endp1, first it will go to the Proxy. At
this point, the proxy can check the policy and decide if the call is
allowed or not (eg: only endp3 can call endp1). At this point the agent
is able to properly qualify both ingress and egress realms, and ask for
a well defined pinhole to be opened.

But this assumes that midcom is used in a specific way - when an actual
call is made, not at the registration moment.

I think the technique is fine, if used with precaution. ??? Is it still
usable? I don't know... I think so, if both ingress/egress realms
(informant addresses) are mandatory in the pinhole request.

Does it make sense?

-Adina

-- 
Adina Simu
Software Engineer
Core IP Eng - Services & Security
IOS Technologies Division
Phone: 408-525-1383

---

From: Scott Brim <[email-masked]>
Date: Thu, 20 Sep 2001 09:43:37 -0400

> endp1  10.0.0.1-|   e1|      |e3   |-3.3.3.1 endp2

Endp1 doesn't need any midcom interaction for inside calls, but in order
for someone to call endp1 from outside, endp1 needs its address mapped
to a globally meaningful address to start with.  Thanks to the wonders
of NAT, endp1 has a different address for inside and outside
connections.

I think your point is that when initially allowing all calls to come in,
endp1 doesn't have any particular informant address for whoever it might
be communicating with yet.  I was assuming we could have some special
bit of syntax for that, like all 0s.  Yet another thing that didn't
actually get put in the draft.  At the registration moment, for outside
calls you need to create a mapping.  The source address is a wildcard *
with 'outside okay' set.  The informant address for the source address
is all 0s.  The destination address is endp1 with an informant address
of endp1.  The request for an action spec is for a global mapping.

> (informant addresses) are mandatory in the pinhole request.

I think the informant address fields are always meaningful.

..Scott