Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

From: "Zmolek, Andrew (Andrew)" <[email-masked]>
Date: Tue, 26 Jun 2001 11:09:25 -0600

Supposing there were a "direction" or "interface" field as some have
proposed, some underlying knowledge of the architecture around the
middlebox must then be shared between the midcom agent and the
middlebox. My question is whether this assumption is reasonable. It
seems to me that either:
 
a) The specific architecture is just a local usage issue and the right
thing will happen in any specific instance, no matter how many distinct
networks are joined at the middlebox because the proper context is set
in other ways. Or,
 
b) Specifying such a field useful only for a deployed agent/middlebox
architecture conforming to a simplified general case and has no value
for anything more complex.
 
On a related note: solving the spoofed address problem seems best done
with protocols that passes both architecture and policy information.
Does midcom really fit the bill for this? I'm not convinced of that at
all.
 
--Andy Zmolek
    Technology & Standards Engineer
      CTO Standards
        Avaya Inc.

            [email-masked]
              +1 720 444 4001

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]]
Sent: Tuesday, June 26, 2001 9:07 AM
To: 'Bob Penfield'; Melinda Shore; Andrew Molitor; midcom
Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

I think having the "direction" field is useful. For cases with NAPT and
SIP, where the NAPT binding can be completed only in later phases of the
session initiation and may be changed again later, the association of a
direction parameter with the pinhole at least gives the Middle-box a
sense of what kind of address to expect to complete the NAPT binding.
This gives some added level of security.

Sanjoy  

-----Original Message----- 
From: Bob Penfield [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Sunday, June 24, 2001 7:30 AM 
To: Melinda Shore; Andrew Molitor; midcom 
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt 

----- Original Message ----- 
From: "Melinda Shore" <[email-masked]> 
To: "Bob Penfield" <[email-masked]>; "Andrew Molitor" 
<[email-masked]>; <[email-masked]> 
Sent: Sunday, June 24, 2001 8:02 AM 
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt 

> > In order to ensure the 
> > desired packet forwarding/admission, the pin-hole would need to be 
> > associated with the interface that the packets would be arriving on.

Packets 
> > arriving on the other interface that happen to match the source
address 
> > prefix/mask for that pin-hole spec would be blocked. 
> 
> I think we're saying the same thing.  Given that 
> we've got source addresses and destination addresses 
> in the IP headers, isn't putting additional directionality 
> information redundant (and potentially confusing if there 
> are conflicts)? 

I think you missed my point. What about a spoofed source address?
Granted 
that stops only one kind of attack on only one side of the middlebox.
Also, 
with all the multi-homing, redundant links and other kinds of complex 
routing isn't it possible, if the middlebox represents the destination 
address of a packet, that packets with the same source and destination
could 
arrive at either side. Maybe that's a stretch, but I'm not a routing
expert. 

If I am implementing a middlebox, being able to have a separate pin-hole

tables for each interface is more efficient. Theses boxes usually need
to 
operate at or near wire-speed. 

(-:bob 

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