Subject: RE: [midcom] Semantics: CHOOSE the destination?

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 17 Jul 2002 03:47:26 -0400

Yes.

-----Original Message-----
From: Scott Brim [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 3:31 AM
To: midcom
Subject: Re: [midcom] Semantics: CHOOSE the destination?

On Wed, Jul 17, 2002 02:45:25AM -0400, Tom-PT Taylor allegedly wrote:
> 
> You definitely describe the behaviour I assumed.  In my mind, the apparent
> inconsistency lies in my use of the term "destination address" for the
third
> address in the tuple.  I thought of "destination" as the ultimate
> destination of the packet, rather than what appears in the destination
field
> of the packet at its origin.  I'll think about whther I should
> redefine/reorder the fields of the filter tuple to produce more consistent
> behaviour.   

You have no idea what was in the packet at its origin.  You mean, when
it arrives at the middlebox?

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Tuesday, July 16, 2002 5:28 PM
> To: midcom
> Subject: [midcom] Semantics: CHOOSE the destination?
> 
> 
> In sec 2.3 of draft-taylor-midcom-semantics-00.txt, it indicates that the
> MIDCOM Agent can request an address+port for the mapped address. If the
> source and destination of a packet are matched against the source and
> destination of a Policy Rule Filter, the destination address for operation
> d) & e) of scenario [3:7-2] (NAPT control) would need to "CHOOSE" the
> destination address. The mapped address would be the internal endpoint
> address + port.
> 
> If the middlebox is suppose to match the received packet's destination
with
> the mapped address of the filter, the usage of the components of the
filter
> would be inconsistent between a firewall pinhole and a NAT translation.
> 
> For an inbound NAT, a packet match would be:
>      src=<source>, dest=<mapped>
> 
> For an inbound pinhole, outbound pinhole, and outbound NAT,
> a packet match would be:
>      src=<source>, dest=<destination>
> 
> There seems to be the same inconsistency in the Stiemerling draft.
> 
> Or is there not suppose to be a direct relationship between the filter
> fields and what the middlebox uses to match packets to rules?
> 
> Forgive me if I am being dense.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> [email-masked]
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom

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

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 18 Jul 2002 12:11:45 -0400

I misinterpreted something you said earlier, with the result that I thought
the double mapping covered this.  I've had a suggestion that we should add a
realm-instance qualifier on the internal addresses to allow for multiple
address spaces or load-sharing Middleboxes.  Does that sound right?

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: Thursday, July 18, 2002 11:52 AM
To: Taylor, Tom-PT [CAR:B602:EXCH]
Cc: midcom
Subject: Re: [midcom] Semantics: CHOOSE the destination?

[snip]

I do have to note that semantics of "direction" does imply that only
middlebox with one internal address space and one external address space are
supported. Are we saying that support for middleboxes with more than two
addresses spaces are out of scope?

cheers,
(-:bob