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

From: Scott Brim <[email-masked]>
Date: Sun, 9 Sep 2001 16:31:42 -0400

I just sent this off to internet-drafts.  Now I can answer all the mail
from last week.  More soon ... Scott

---

From: Mark Duffy <[email-masked]>
Date: Thu, 13 Sep 2001 17:28:47 -0400

Scott, thanks.  I'm still working on digesting this document but I do have
a few comments.

.  Having the middlebox determine whether the addresses are inside or
outside seems like an elegant solution.  (At least, if it is a solution :-)
 I'm not yet convinced of that.)

.  I believe this proposal assumes that the middlebox understands the
topology at least well enough to determine inside/outside as f(IP address).
 It seems to me that might not be true of all middleboxes.  For example
consider a simple 2-port middlebox that makes its forwarding decision based
on 'forward the packet out whichever interface it did not arrive on'.

.  This proposal does not directly address middleboxes with multiple
"inside" realms (such as network-based middleboxes).  I suppose that could
be addressed by modeling such a middlebox as multiple virtual middleboxes,
each with a simple inside/outside as we have discussed in earlier emails.
Of course, that really just pushes more of the problem onto a middlebox
discovery mechanism.

--Mark

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

---

From: Adina Simu <[email-masked]>
Date: Thu, 13 Sep 2001 15:14:42 -0700

Mark,

please see inline

> on 'forward the packet out whichever interface it did not arrive on'.

I think I'm missing something in your example. What do you mean by
"forward the packet out"? What if the packet is coming from "out"?
Please be more specific.

> "inside" realms (such as network-based middleboxes).  I suppose that could

Limiting for a minute the discussion to NAT middleboxes, the proposal
works fine no matter how many "Inside" and "Outside" realms are.

On this subject, there's something to be noted on the topology from Bob
Penfield's draft:

        +-------------+ 
        |             |           +------+ 
        | Customer A  |           |      |      +---------------+ 
        |             +-----------+      |      |               | 
        |  10.0.0.x   |           |      |      |               | 
        |             |           |      |      |   Service     | 
        +-------------+           |Middle|      |   Provider    | 
                                  |  Box +------+               | 
        +-------------+           |      |      |               | 
        |             |           |      |      |  192.168.20.x | 
        | Customer B  |           |      |      |               | 
        |             +-----------+      |      +---------------+ 
        |  10.0.0.x   |           |      | 
        |             |           +------+ 
        +-------------+ 

If you want connectivity in all possible combinations (Cust A - Cust B,
Cust A - Serv Prov, Cust B - Serv Prov), this cannot be achieved with
today's NATs (by this I mean NAT as described in NAT RFCs) - for routing
reasons. I can provide more details if needed...

Thanks
-Adina

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

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Sep 2001 19:11:42 -0400

On Thu, Sep 13, 2001 05:28:47PM -0400, Mark Duffy allegedly wrote:
> Scott, thanks.  I'm still working on digesting this document but I do
> have a few comments.
> 
> outside seems like an elegant solution.  (At least, if it is a
> solution :-) I'm not yet convinced of that.)

I'm pleased at your first impression :-).  We're just trying to keep
things simple.

> topology at least well enough to determine inside/outside as f(IP
> address).  It seems to me that might not be true of all middleboxes.
> For example consider a simple 2-port middlebox that makes its
> forwarding decision based on 'forward the packet out whichever
> interface it did not arrive on'.

In this draft, inside and outside are not absolute, but are from the
point of view of who is speaking, in particular an agent.  When an agent
says "outside okay" for an address, it means that address can refer to
something in a different trust or addressing realm (across the
middlebox).  

If a middlebox has multiple interfaces into the same addressling realm,
it had better be configured to know that.  That's a different case from
the simple bump-in-the-wire, and inside/outside still work as above.

> "inside" realms (such as network-based middleboxes).  I suppose that
> could be addressed by modeling such a middlebox as multiple virtual
> middleboxes, each with a simple inside/outside as we have discussed in
> earlier emails.  Of course, that really just pushes more of the
> problem onto a middlebox discovery mechanism.

First, let me be sure out what you mean.  Do you mean an agent in a
service provider network which has two or more client networks, where
the client networks have overlapping private address spaces?  In that
case what you call those multiple "inside" realms would be "outside" to
the agent.  Right?  The inside/outside designation doesn't have to do
with the clients, it's in the midcom protocol, and about the
relationship between the agent and the middlebox.  

Or, do you mean networks which share a single address space but are only
connected through the middlebox functioning as a router, and are thus
all "inside" from the point of view of each other?  I think I'll dismiss
that one, since it doesn't involve the middlebox NAT function.  

Assuming you mean the former ...

There was a little section that mentioned this (rummage rummage ...)
Section 9.  We didn't put any detail in there -- I thought it would be a
distraction.  Yes, you could make multiple virtual middleboxes out of
them, but you can theoretically also use the informant address
technique, as follows.  

It doesn't matter which of the networks the agent and clients are in,
the agent and NAT behavior are the same.  In fact let's even assume the
worst case, that there are (at least) three overlapping address spaces,
all connected by one NAT, for symmetry.  From the point of view of the
agent, all addressing realms except its own are "outside".

If you're just setting up open admission, for example to receive calls,
and you're accepting connections from outside of your addressing realm,
then you don't care where from -- so you just say "outside okay", and
the NAT does not need to distinguish between those outside realms --
when packets come in on any interface it will create a locally unique
address for whoever sent them, and know the reverse transform.

If you're setting up a specific rule, either for an address or an
address range in a particular foreign addressing realm, then you must
have acquired a target address (or address range) for that specific rule
somewhere -- say from a SIP invitation or DNS -- and so you must already
have a unique address for an informant, already allocated by the NAT.
Given your informant address the NAT will know what to do, just as it
knows what to do for incoming packets in the previous paragraph. 

Did I miss anything?

If your mapping for the informant was provided by one middlebox and your
data is going to go through a different one, you run into discovery
problems.  I think this issue is common to both proposed solutions,
although it manifests itself differently in each.  I suppose we need to
make sure we're not requiring too much of discovery.  Let's do that in
another thread.

..Scott

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Sep 2001 19:12:30 -0400

> reasons. I can provide more details if needed...

I should mention that my previous mail was based on theory :)

---

From: Mark Duffy <[email-masked]>
Date: Thu, 13 Sep 2001 23:53:42 -0400

Hi Adina, see below...  -Mark

>"forward the packet out"? What if the packet is coming from "out"?

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.

>works fine no matter how many "Inside" and "Outside" realms are.

In the diagram below, suppose Customer A and B each have a host 10.0.0.1
and the middle box is doing NAT (not NAPT).  Suppose Customer A 10.0.0.1 is
bound to 192.168.20.1.  Suppose Customer B 10.0.0.1 is bound to
192.168.20.2.  Now, when a midcom agent asks "what is the NAT binding for
10.0.0.1", how does the middlebox respond?

>On this subject, there's something to be noted on the topology from Bob
[snip]

---

From: Adina Simu <[email-masked]>
Date: Thu, 13 Sep 2001 21:31:52 -0700

Mark,

please see inline...

> there are middleboxes of this sort.  I  believe such a middlebox would be

I'm not familiar with such middleboxes... I don't see how NAT would run
on such a box. Not sure about FW.

> examining target or informant addresses whether they resided inside or

<snip>

> 10.0.0.1", how does the middlebox respond?

Where is the agent located? If it's in the SP realm, the only way for it
to aquire the 10.x address would be through a packet coming from a 10.x
net - which would have been translated, so the source IP in the packet
header would be either 192.168.20.1 or .2 - based on that NAT will
identify which 10.x ...

The idea behind the informant address is very basic: suppose a
pre-midcom network, where ALG reside on the NAT box. When NAT has to
translate an embedded address, it figures out the topology information
(the realm where the address was originated and where is it going) from
the IP addresses in the header. An agent should provide the same info to
a middlebox doing NAT.

Thanks
-Adina

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 14 Sep 2001 08:23:07 -0400

> On this subject, there's something to be noted on the topology from Bob
Existing NAT boxes may not do this today, but there are a number of VOIP
service providers that want devices like this and there are people building
them. MIDCOM needs to consider both existing middlebox and those that people
are developing today. Currently, product developers must use a proprietary
protocol to talk to these middleboxes. They (we) would like to be able to
use a standardized protocol in the near future. The solution proposed in
draft-brim-midcom-inandout-00.txt does not cover the case of CustomerA to
Customer B traffic. If all you have two 10.0.0.x addresses (informat &
target), there is no way for the middlebox to tell which private realm those
addresses are in unless the agent in the service provider gives it a hint.

cheers,
(-:bob

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2001 08:50:54 -0400

> addresses are in unless the agent in the service provider gives it a hint.

Please read the draft and/or the mail more carefully.  The informant
address will not be a 10.0.0.x address.  The informant address will have
already been mapped through the NAT, since the agent is already
exchanging packets with it.  It will be locally unique in the realm of
the agent, e.g. 192.168.20.241.  In the case of SIP, when you receive an
invitation to 10.0.0.9, you will receive it in a packet with a source
address of 192.168.20.241.  That's your informant address.  When you
pass that back to the NAT as the informant address, since it already has
a mapping for the informant address, the NAT will know how to resolve
your request.  You already have all the hint you need.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 14 Sep 2001 09:16:22 -0400

----- Original Message -----
From: "Adina Simu" <[email-masked]>
To: "Mark Duffy" <[email-masked]>
Cc: "Scott Brim" <[email-masked]>; <[email-masked]>
Sent: Friday, September 14, 2001 12:31 AM
Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt

> the IP addresses in the header. An agent should provide the same info to
When you say "the same info", I believe that part of that info is the
interface that the packets arrive on. The question is, how does a midcom
agent provide that piece of information. Supplying 2 addresses from a
private address space is no more helpful that providing 1 if you have more
than one overlapping private address spaces. Given that, how does a midcom
agent provide "the realm where the address was originated and where is it
going"?

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2001 10:43:01 -0400

> agent provide "the realm where the address was originated and where is it

I already answered this in my previous message.

---

From: Mark Duffy <[email-masked]>
Date: Fri, 14 Sep 2001 11:25:43 -0400

Scott, see comments below...

[snip]
>something in a different trust or addressing realm (across the

Suppose the middlebox is a very simple one that only knows that interface A
connects to one side (lets call it the inside") and interface B connects to
the other side ("outside").  I.e. "inside" and "outside" are *defined by*
interfaces A and B.  The middlebox applies rules to the traffic based on
packet n-tuple, interface the packet arrived on, and transport layer state
accumulated in the middlebox.  Now, if I understand your draft the agent in
effect says:

   "Install this ruleset, unless it is not needed because both the 
    source and destination addresses are on the same 'side'.  Here is
    an informant address also, to help you decide."

It seems to me, that this simple middlebox has no idea where any particular
addresse lie, and so I am wondering how it could possibly deal with such a
request from an agent.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 14 Sep 2001 11:35:26 -0400

----- Original Message -----
From: "Scott Brim" <[email-masked]>
<snip>
<snip>>
> your request.  You already have all the hint you need.

I see. However, this assumes that signalling packets traverse the same
middlebox that the application entities want to put the data packets
through.

But anyway, I think I see how this can be done, let me give an example.
Using the picture above, and assuming the midcom agent is collocated with an
application entity in SP. The NAT bindings between application entities in
A, B, and SP would need to be established before any application signaling
traffic. For example, the application entities in A and B could initiate TCP
connections to the application entity (let's call them AEs) in SP. For an
application session to be established between A and B, a signaling message
would be sent from the AE in A to the AE in SP. The AE in SP determines that
this signaling message should go to the AE in B. The signaling message
contains the private IP address in A that must be NAT'd to a public address
in SP in order to get through the middlebox. The AE in SP needs to request a
NAT binding, but what it wants is "for all packets arriving on the interface
from customer B with a destination address equal to a public address you
(the middlebox) assign, forward them to the interface to customer A and
change the destination address to this private address". Now, in order to
communicate this, it needs to send both previously established public
addresses associated with AE NAT bindings.

Let me give some concrete values.

- connection from AE-A to AE-SP gets 192.168.20.241 as a public address
- connection from AE-B to AE-SP gets 192.168.20.242 as a public address

- endpoint A is 10.0.0.9 in A

- as the signaling traverses AE-SP, AE-SP determines that AE-B is the next
hop, the midcom agent needs to get a public address for endpoint A as a
target for the data packets that will be coming from the endpoint in B
(AE-SP assumes the endpoint is in B, or beyond, because the next hop AE is
in B). The request to the middlebox would look something like this:

    Ingress Informant = 192.168.20.242   (i.e. realm B)
    Incoming Source = any
    Incoming Destination = pick one
    Egress Informant = 192.168.20.241  (i.e. Realm A)
    Outgoing Source = pick one
    Outgoing Destination = 10.0.0.9

- The signaling going back from B to A would have a similar ruleset with the
Ingress & Egress informants swapped, and the Outgoing Destination would be a
private address in B.

Does this seem correct?

(-:bob

---

From: Scott Brim <[email-masked]>
Date: Fri, 14 Sep 2001 11:43:05 -0400

> addresse lie, and so I am wondering how it could possibly deal with such a

The worst case you're describing is a complex private network, with
routers, on one side, and the public network on the other side, while
the device in the middle has no knowledge whatsoever -- it's just a
firewall with whatever holes are explicitly punched through.  I think
you're right.  I think we don't handle that case (unless someone can
tell me how).  If the firewall had an address/mask pair configured on
the "inside" interface, even if it had nothing more, then we could.

I hope you won't say, "Aha, I found an unusual case you can't handle,
therefore we have to use the alternative, even though it adds much more
complexity for the much more common cases".

..Scott

---

From: Mark Duffy <[email-masked]>
Date: Fri, 14 Sep 2001 11:51:15 -0400

Scott, comments on the 2nd part (I split the issues)  --Thanks, Mark

>the client networks have overlapping private address spaces? 

Yes.

>                                                              In that

I don't understand that, actually.  I have always viewed the realms (which
we are here reducing to "in" and "out") as being an administrative concept
defined by the administrator of a realm.  Since middleboxes cost money,
they are installed only when a particular need exists such as to provide
firewall to protect access to a domain, or to provide NAT so that a
private-address domain may communicate with the outside world.  As such,
the middlebox forms the boundary between in and out, and so in and out may
be measured relative to the middlebox.  AFAIK, midcom allows an *agent* to
be on any side of the middlebox, i.e. in or out.   I don't think the
relationship between the agent and the middlebox serves in any way to
define what is in and what is out. 

>Assuming you mean the former ...

Yes.

>knows what to do for incoming packets in the previous paragraph. 

Well, maybe.  I don't understand how this would work:
Suppose a midcom agent is "inside" one of the multiple, overlapping,
private-address domains served by a NAT middlebox.  And that agent queries
the mb to ask it "What public address/port pair is 10.0.0.1 tcp port 23
bound to?".  Since there may be a different answer to that query for each
private domain supported by the mb, the mb needs to figure out which one to
return.  One way it could do this is by observing which realm the midcom
query was received from.  Or do you think the draft offers another way?

---

From: Mark Duffy <[email-masked]>
Date: Fri, 14 Sep 2001 12:05:38 -0400

>the IP addresses in the header. An agent should provide the same info to

Ah!  And there is the crux of the matter.  "An agent should provide the
same info to a middlebox doing NAT."   We have ~2 proposals on the table
for *how* the agent expresses that info:  by naming the interface or realm
to the middlebox (other drafts), or by providing IP addresses from which
the middlebox must deduce the realm (Simu/Brim draft).  I see pros and cons
to both.  

Not that it it is directly relevant, but if one considers the pre-midcom
case (can we call it legacy yet?  :-)  with ALG residing in the mb, it
effectively works the first way (naming the interface or realm).  The
operator configures rules whose parameters include interface and direction.

--Mark

---

From: Mark Duffy <[email-masked]>
Date: Fri, 14 Sep 2001 12:16:10 -0400

>complexity for the much more common cases".

Well, I certainly am not saying Aha.  

I would say, "I am not sure how unusual this scenario is but hopefully some
others on the list have a better knowledge of that than I."

I am just trying to explore the pros and cons of the available approaches.

-Mark

---

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

Please see inline

> Ingress & Egress informants swapped, and the Outgoing Destination would be a

Yes it looks correct... I do have 1 question though. If the scenario
you're describing is: A talks to SP, then SP decides the final
destination is B, forwards the packet to B, then B and A talk, then I
think you need an extra agent in either A or B. Am I right?

Thanks
-Adina

---

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

> operator configures rules whose parameters include interface and direction.

Mark, you're absolutely right. But what reason do we have to propagate
this info now to the agent? This is exactly the point of our proposal.

Thanks
-Adina

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 14 Sep 2001 14:17:46 -0400

----- Original Message -----
From: "Adina Simu" <[email-masked]>
To: "Bob Penfield" <[email-masked]>
Cc: "Scott Brim" <[email-masked]>; <[email-masked]>
Sent: Friday, September 14, 2001 1:18 PM
Subject: Re: [midcom] draft-brim-midcom-inandout-00.txt

> think you need an extra agent in either A or B. Am I right?
If you mean a midcom agent, then the answer is no. In this scenario, the
service provider owns the middlebox. There is only one midcom agent which is
co-located with the application entity in the service provider network
(AE-SP). There could be midcom agents in either A or B, but it is not
required.

(-:bob

---

From: Scott Brim <[email-masked]>
Date: Sun, 16 Sep 2001 12:45:37 -0400

This may alread be covered but for completeness ...

On Fri, Sep 14, 2001 11:51:15AM -0400, Mark Duffy allegedly wrote:
> >case what you call those multiple "inside" realms would be "outside"
> >to the agent.  Right?  The inside/outside designation doesn't have to
> >do with the clients, it's in the midcom protocol, and about the
> I don't understand that, actually.  I have always viewed the realms
> (which we are here reducing to "in" and "out") as being an
> administrative concept defined by the administrator of a realm.  Since
> middleboxes cost money, they are installed only when a particular need
> exists such as to provide firewall to protect access to a domain, or
> to provide NAT so that a private-address domain may communicate with
> the outside world.  As such, the middlebox forms the boundary between
> in and out, and so in and out may be measured relative to the
> middlebox.  AFAIK, midcom allows an *agent* to be on any side of the
> middlebox, i.e. in or out.   I don't think the relationship between
> the agent and the middlebox serves in any way to define what is in and
> what is out. 

Words.  Feh.  Let me try.  I think you are making "inside" synonymous
with "enterprise" or something.  Yes, in and out are measured relative
to a middlebox, but which one is in and which is out?  That depends
who's looking.  In the informant address scheme, inside/outside only
comes up at one point -- when an agent wants to say that a particular
address or range can be allowed to refer to something outside of the
requesting agent's trust or address realm.  We used "outside" for that
meaning.  If you want inside/outside to refer to something absolute in
terms of middlebox configuration, as opposed to something relative to
the other end of a particular midcom protocol session, I could change
the name of the flag to "foreign okay" or something.

> private-address domains served by a NAT middlebox.  And that agent
> queries the mb to ask it "What public address/port pair is 10.0.0.1
> tcp port 23 bound to?".  Since there may be a different answer to that
> query for each private domain supported by the mb, the mb needs to
> figure out which one to return.  One way it could do this is by
> observing which realm the midcom query was received from.  Or do you
> think the draft offers another way?

(1) Are foreign addresses okay?  (2) What's the informant address?
These two bits of information give the context in which to interpret
10.0.0.1.

(Aside: the question is in error.  There might not be any public
address.)

..Scott

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 18 Sep 2001 17:01:53 -0400

Scott,

I do believe that the informant address scheme can work even in scenarios
with multiple outside realms with overlapping addresses. In scenarios where
the informant addresses are learned from the signaling streams, it does
require that the signaling traverses the middlebox. In the case of two
"outside" realms with potentially overlapping addresses, you would need to
supply 2 informant addresses to the middlebox. Let me illustrate:

         10.0.0.7    Realm A !
           +----+            !               Realm SP
      .....|AP-A|......      !
     /     +----+      \    +------+A=192.168.20.241
 +----+                 \...|.....A|.................+-----+
 |EP-A+->-------------------|-->Y  |                 |     |
 +----+<--------------------|<+ |  |Y=192.168.20.243 |AP-SP|
10.0.0.2                    | | |  |                 |     |
                            | | |  |                 |     |
- - - - - - - - - - - - - - | | |  |=================|MA   |
                            | | |  |                 |     |
10.0.0.2                    | | |  |X=192.168.20.244 |     |
 +----+->-------------------|>X |  |                 |     |
 |EP-B+<--------------------|<--+  |        .........+-----+
 +----+               ......|.....B|......./           192.168.20.1
     \     +----+    /      +------+B=192.168.20.242
      \....|AP-B|.../        !
           +----+            !
           10.0.0.9  Realm B !

.../ represents the signaling messages flowing between application end
points (EPs) and application proxies (APs).

==== represents the midcom messages from the midcom agent (MA) co-located
with AP-SP.

---- represents the media/data flows between the application end-points
(EP).

For this illustration, consider Realm SP to be "inside" and Realms A and B
are "outside". The signaling connections between the outside APs and the
inside AP are NATed by the middlebox. A=192.168.20.241 is the inside address
of AP-A. B=192.168.20.242 is the inside address of AP-B. As the signaling
traverses AP-SP it knows the previous hop is AP-A and determines through
some unknown location service or logic that the next hop is AP-B. At this
point, the MA in AP-SP communicates with the middlebox to establish NAT X
that allows packets from the terminating endpoint EP-B to flow to the
originating endpoint EP-A. X would be an inside address that EP-B would use
as the destination address for its packets. Packets sent to X would be NATed
to EP-A's outside (private) address. Both A and B informant addresses are
passed in the midcom message to tell the middlebox that packets come in the
interface to A and go out the interface to B.

As the signaling response from EP-B & AP-B traverse AP-SP, it determines
that the next hop is AP-A and communicates with the middlebox to establish
NAT Y which allows packets to flow from EP-A to EP-B. Y is an inside address
that EP-A sends data packets to which get NATed to EP-B's private address.

If an informant address is used for both the egress and ingress realms, then
it does not matter how many "outsides" are connected to the middlebox. As
long as you have an inside address known to the midcom agent that the
middlebox has mapped to the outside realm, it will work. If the middlebox
did not find a mapping for the informant address, it could tell the midcom
agent that the middlebox is not needed.

Now, this does assume that the signaling messages traverse the middlebox and
that AP-SP learns inside addresses for the outside APs when the outside APs
connect to (initiating communication with) AP-SP. These mappings (NATs for
the signaling streams) would need to be established by midcom agents in
realms A and B OR pre-configured into the middlebox.

A single informant address will suffice when the flows go from one outside
realm to the inside realm.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Scott Brim <[email-masked]>
Date: Wed, 19 Sep 2001 11:20:09 -0400

> supply 2 informant addresses to the middlebox. Let me illustrate:

I think you've got it.  

>  +----+<--------------------|<+ |  |Y=192.168.20.243 |AP-SP|

That really is an awesome diagram.

> interface to A and go out the interface to B.

Right.  The infrastructure -- NAT mappings or whatever -- for the agent
to communicate with the remote APs is already in place before the agent
makes the midcom request.  The agent already has informant addresses
that work.

> realms A and B OR pre-configured into the middlebox.

When signaling passes through one middlebox and data through another,
and you have this multiple-overlapping-address-space situation, then we
might have a problem.  If the NAT functions map to globally unique
addresses, and routing/configuration is working properly, then you're
all right -- the agent will send a request to the second NAT using
*global* addresses for the informants, and that NAT will still know
where they are based on ordinary routing/configuration.

> realm to the inside realm.

In that case you still have two informant addresses but one of them will
be inside.  It might be the agent itself, for example if the agent is
proposing a wildcard or if an address is configured statically.  It
might be the original client the agent is acting on behalf of, or an
application proxy separate from the agent, or some internal policy
server.  Wherever the agent learned that target address.  In this one
respect the agent should be dumb.

Thanks ... Scott