Subject: [Ietf-behave] RE: AD evalution comments on draft-ietf-behave-nat-udp-05

From: "Francois Audet" <[email-masked]>
Date: Thu, 20 Apr 2006 09:29:36 -0700 (PDT)

Thanks Magnus and Cullen.

I'll make all the changes where we have resolution.

Here are the remaining issues from the list.

> >> 3. Section 4.2.1, page 9, fifth paragraph:
> >>
> >> "It should be noted that port 0 is reserved and must not be used."
> >>
> >> I think there are a number of ports that would be 
> confusing to use as 
> >> source ports. One especially would be port 9 (discard). Thus two 
> >> questions to the WG. Should it be pointed out that there 
> are several 
> >> ports that are not suitable as source ports, and secondly should 
> >> these be enumerated?
> 
> No comments on this issue?

My recommendation would be to delete the sentence "It should be noted
that port 0 is reserved and must not be used". I don't think it is
useful
to start ennumerating all the ports that shouldn't be used.

> >> 5. Section 4.3: REQ-5:
> >>    "A NAT UDP mapping timer MUST NOT expire in less than 1 minute,
> >>        unless REQ-5a applies.
> >>        a) A NAT MAY have UDP mapping timers that have much shorter
> >>           timers, but only for specific ports in the 
> well-known port
> >>           range (i.e., ports 0-1023) where the IANA- 
> registered protocol
> >>           is strictly a request/response protocol, such as 
> for example
> >>           DNS over UDP/53.
> >>        b) The value of the NAT UDP mapping timer MAY be 
> configurable.
> >>        c) A default value of 5 minutes for the NAT UDP 
> mapping timer is
> >>           RECOMMENDED."

We have been trying to balance our requirement for timer values between
what makes sense for "residential-grade" NATs versus large Enterprise
NATs (who happens to be Firewall at the same time).

The larger timers make sense for the residential-grade NATs. Req 5-c is
useful for residential-grade NATs, because often, the manufacturers are
very amiable to a recommended default.

What we have found however is that the Enterprise NAT vendors where
quite
uncomfortable with long timers. The change from "2 minutes" to "1
minute" for 
the minimum was a result of request from Enterprise NAT vendors. We are
a bit
worried that if the timer is too long, they will simply ignore the
requirement. 
Req 5a was introduced to allow for optimizations that are very common
for 
large Enterprise NATs.

So, I think we have three options:
a - Keep the original value (before -05), which was 2 minutes.
b - Keep the lower limit from the -05 draft, which is 1 minute
c - Use 3 minutes, as per Magnus and Cullen's dialog

Personally, I think that we should revert to what we had before -05
which is
the 2 minutes. It seems to me that we circled the argument many times
now,
and that it is the best compromise.

But I'm happy with any of those values.

> >> 9. Section 10.2, REQ-14:
> >>
> >> I don't see how this requirement is connected to the section text? 
> >> Also it is not clear if there is anything more than what 
> is described 
> >> in section 9 and 10.1 that needs to be supported. I think some 
> >> clarification and text changes in regards to this is needed.
> > 
> > I might be missing what you are saying here but .... are 
> you thinking 
> > changing
> > 
> > REQ-14: A NAT MUST support fragmentation of packets larger than link
> >       MTU.
> > 
> > to something more like
> > 
> > REQ-14: A NAT MUST support fragmentation of packets larger than link
> >       MTU by sending an ICMP for any packet larger than the 
> MTU when 
> > DF=1 and in the case where DF=0, either break the packet into 
> > fragments smaller than the MTU or send an ICMP error.
> > 
> > Clearly this text would need to be changed to make sense but just 
> > wanted to make sure I was understanding the scope of the 
> change here.
> > 
> 
> What I don't understand is what is different in Req-13 and 
> Req-14. To me 
> REQ-13 applies independently if the packet is going from the 
> internal to 
> the external or vice versa.

Dan, can you expand on this?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Apr 2006 09:57:45 -0700 (PDT)

> > >> 9. Section 10.2, REQ-14:
> > >>
> > >> I don't see how this requirement is connected to the section
> > >> text?  Also it is not clear if there is anything more than what
> > >> is described in section 9 and 10.1 that needs to be supported.
> > >> I think some clarification and text changes in regards to this
> > >> is needed.
> > >
> > > I might be missing what you are saying here but .... are you
> > > thinking changing
> > >
> > > REQ-14: A NAT MUST support fragmentation of packets larger than
> > > link MTU.
> > >
> > > To something more like
> > >
> > > REQ-14: A NAT MUST support fragmentation of packets larger than
> > > link  MTU by sending an ICMP for any packet larger than the
> > > MTU when DF=1 and in the case where DF=0, either break the
> > > packet into fragments smaller than the MTU or send an ICMP
> > > error.
> > >
> > > Clearly this text would need to be changed to make sense but
> > > just wanted to make sure I was understanding the scope of the
> > > change here.
> > >
> >
> > What I don't understand is what is different in Req-13 and Req-14.
> > To me REQ-13 applies independently if the packet is going from the
> > internal to the external or vice versa.
>

(I contributed this text in the document.)

Req-13 describes a UDP packet arriving at the NAT that is larger
than the MTU for the next interface.  Yes, it applies independently if 
the packet is going from internal to external or vice versa.

It describes expected behavior depending on the DF bit.  This is 
arguably not UDP specific, but we lack a "for all protocols" 
document; the intent is to echo the requirements for DF handling 
that are in RFC1812.

Looking at this again, the current text in -05 reads:

   REQ-13: If the packet has DF=1, the NAT SHOULD send back an ICMP
      message "fragmentation needed and DF set" message to the host as
      described in RFC 792 [2].
      a) If the packet has DF=0, the NAT SHOULD fragment the packet and
         send the fragments, in order.

and could be improved by changing it to:

  REQ-13: If a UDP packet needs to be routed to a link with a smaller
     MTU, and
     a) the DF bit is set, the NAT MUST send back an ICMP 'fragmentation
        needed and DF set' message to the originating host as described
        in RFC792 [2].
     b) the DF bit is clear, the NAT SHOULD fragment the packet and
        SHOULD send the fragments in order.

The text around Req-14 (that is, the text of section 10.2) describes 
what the NAT should do when it, itself, receives an ICMP message.  
The text of section 10.2 and its Req-14 (which needs to be 
rewritten, as Req-14 is inaccurate) should be moved into an ICMP
document, as this behavior is not specific to UDP.

Thanks for catching this, Magnus.

-d

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 23 Apr 2006 20:13:46 -0700 (PDT)

--- Francois Audet <audet@xxxxxxxxxx> wrote:
...
> But I'm happy with any of those values.
[suresh] I agree, makinng the timers long can be problematic to a number of NAT
vendors, especially those that make low-end NAT devices with limited resources.
NAT vendors fine tune these timeouts to suit their customer environmets. If
IETF mandates the timeouts to be long, the vendors could run into support
problems they had not not anticipated as NATs run out of resources quickly.
IETF will not be there to help them with the support issues. 

My vote is to keep the timer at 1 minute. I believe, setting this to more than
2 minutes  could potentially invite unknown support issues. Many vendor might
in turn choose not to adapt the madanted timeouts. My 2c.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 23 Apr 2006 20:20:30 -0700 (PDT)

Basically, both requirements (Req-13 and Req-14) are RFC 1812 requirement for
routers, not specific to NAT devices. The requirements are also not UDP
specific and apply to all IP protocols.

ICMP behave document also had requirements that directly overlapped with the
above. In the last WG meeting, Lars commented that NATs should essentially
confirm to RFC 1812. During a subsequent e-mail converation with Dan, Dan and
the authors of the ICMP draft agreed that was the right thing to do. In the
next rev of the ICMP draft, we are going to synthesize these and other such
requirements into a single requirement stating that NATs should confirm to
RFC-1812 router requirements in  IP packet handling and list the specific ICMP
requirements as examples under that requirement.

Since both requirements (Req#13, Req#14) are not protocol specific and are to
do with genrating/processing ICMP errors, may I suggest that these requirements
be  dropped from the UDP draft and just be included in the ICMP behave draft.

regards,
suresh

--- Dan Wing <dwing@xxxxxxxxx> wrote:

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 24 Apr 2006 00:53:23 -0700 (PDT)

Pyda Srisuresh wrote:

My vote is to keep the timer at 1 minute. I believe, setting this to more than
2 minutes  could potentially invite unknown support issues. Many vendor might
in turn choose not to adapt the madanted timeouts. My 2c.
Okay, but what is worst, unknown support issues or practical issues such 
that wireless devices will drain their batteries much faster? Unless you 
can point to actual practical problems I suggest we raise it at least to 
two minutes. I would have liked 5 min but do understand that goes beyond 
the commonly used 3 minutes which I agree have to large potential to 
create issues with deployed NATs.

To me this is a discussion on finding the point where we break so few 
bad implementations, while still representing an actual functionality 
gain, thus creating a situation where deploying behave compliant NATs is 
an advantage and do happens.

I do hope that we can raise the bar a bit and not simply take the 
smallest common denominator. We are after all doing this on a number of 
other points in these requirements.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Apr 2006 09:39:28 -0700 (PDT)

I would like to make a comment about low end NAT vendors. Most comments I
make are just my opinion but this morning I contacted the relevant engineers
and Linksys and am passing on the information from Linksys. I believe and
support all this information.

Linksys is by far and away the number one NAT vendors when measured by
number of units shipped. None of the Linksys NATs have a time out value as
low as one minute for this timer. There is no problem with running out of
ports on any of the residnetintial NATs and that is not a concern. Even with
heavy P2P applications, port depletion is not an issue. The memory to store
state for a large number ports is a very small portion of the total memory
budget for the devices and not an issue.

In conversations with Netgear and DLink, I believe they have very similar
beliefs on all this - basically all the low end NAT manufactures are using
very similar code bases on nearly identical hardware so it is not surprising
that if this is not a problem for any of them.

I don't in anyway believe that a 1 minute time out will be useful for the
residential style NATs. I don't know anyone involved with building these
style NATs that believes that 1 minute is needed - there might be someone
but I have not seen them post to the list or talk to me.

I did not go and discuss this issue with the people that build high end
enterprise style NATs at Cisco.

This is a tradeoff between running out of ports on the NAT, and running out
of bandwidth on the link and processing keep alive transactions on the
servers and batter life on mobile clients. Many people have expressed many
concerns about having this number too low.

Cullen <with my individual contributor hat on and passing on data from
Linksys>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Apr 2006 09:39:29 -0700 (PDT)

>>         needed and DF set' message to the originating host as described

This was discussed in meetings long ago and found unacceptable. Many
firewall and NATs are configure not to send ICMP responses to packets such
as this. There is no application need to make all these devices non behave
compliant so this was rejected. A NAT behaves like a a router some of the
time but the goal of a firewall or NAT is not the same as a router.

Cullen <with my individual contributor hat on>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 24 Apr 2006 10:09:08 -0700 (PDT)

From: "Magnus Westerlund" <magnus.westerlund@xxxxxxxxxxxx>

To me this is a discussion on finding the point where we break so few bad 
implementations, while still representing an actual functionality gain, 
thus creating a situation where deploying behave compliant NATs is an 
advantage and do happens.

I do hope that we can raise the bar a bit and not simply take the smallest 
common denominator. We are after all doing this on a number of other 
points in these requirements.

Cheers

Magnus Westerlund
I agree with Magnus here.

BEHAVE is chartered to develop Best Current Practice specifications, and 
there needs to be a balance between what's "Best", and what's "Current"...

Thanks,

Spencer

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Apr 2006 16:33:21 -0700 (PDT)

When I wrote my email, I did not understand that this requirement only
applied to outgoing packets - if we could make it clear that this only
applies to packets from the internal to external direction, I'm fine with it
because at that point I think it is what the WG previously agreed to.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Apr 2006 16:33:22 -0700 (PDT)

> there needs to be a balance between what's "Best", and what's "Current"...

Me too :-)

---

From: "Ariel Shaqed (Scolnicov)" <[email-masked]>
Date: Tue, 25 Apr 2006 01:25:21 -0700 (PDT)

On Monday 24 April 2006 10:53, Magnus Westerlund wrote:
> Pyda Srisuresh wrote:
> > [suresh] I agree, makinng the timers long can be problematic to a
> > number of NAT vendors, especially those that make low-end NAT devices
> > with limited resources. NAT vendors fine tune these timeouts to suit
> > their customer environmets. If IETF mandates the timeouts to be long,
> > the vendors could run into support problems they had not not
> > anticipated as NATs run out of resources quickly. IETF will not be
> > there to help them with the support issues.
> >
> > My vote is to keep the timer at 1 minute. I believe, setting this to
> > more than 2 minutes  could potentially invite unknown support issues.
> > Many vendor might in turn choose not to adapt the madanted timeouts.
> > My 2c.
>

Some bad things:

1. Not only the 1st NAT on the path is affected.  If an application sends 
keepalives every 2 minutes it will not work with firewalls anywhere along 
its path that keep a smaller timeout for UDP connections and also inspect 
the protocol.  It is probably not very practical to hold a UDP connection 
(i.e. its current state) open on a firewall for 5 minutes of inactivity.

Note that even 0 bits of stored state can make the difference: Consider a 
firewall dropping all UDP connections in one direction.

It make sense to specify minimal timeouts, just not for all UDP ports.

2. The above, when the firewall is NATting its internal domain.

3. Some UDP connections are extremely short-lived.  An example with port> 
1024 is RADIUS, which (in some modes) performs many short exchanges.  The 
requirement limits the number of concurrent sessions possible.  There are 
<65000 ports available for NAT.  If we reserve ports for 300 seconds this 
yields a sustained rate of <216 connections per second to a given server.

It is acceptable for a residential NAT, probably not for #2 above.

> other points in these requirements.

The issue here is not (just) of poor existing implementations.

-- 
Ariel Scolnicov.

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 06:13:41 -0700 (PDT)

I couldnt agree more. Ariel has nicely articulated the issues.

It is a fine balance between short lived applications and applications that may
need long pauses. Increasing the timeout will impact conenction rate for
applications. This effects enterprise NATs more than the residential NATs.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 06:33:29 -0700 (PDT)

> Cullen <with my individual contributor hat on>
[suresh] What are you talking about, Cullen? You sound confused. You are
certainly not responding to the text I sent on this thread. The WG did not
object to NATs sending an ICMP 'fragmentation needed and DF set' message,
AFAIK,

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 06:40:44 -0700 (PDT)

Cullen - Sounds like, you are mixing up threads. You are not responding to the
text I sent on this thread. Req-13 applies to both directions, AFAIK. That is
not what we are talking about, though.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 07:06:47 -0700 (PDT)

Thank you for the feedback from Linksys. What is the UDP timeout used on the
LinkSys, NetGear, D-Link and other residential NAT devices? What are the bounds
to the limits they are willing to accept? 

There are a number of enterprise/data-center devices that embed NAT
functioanlity within. They have resource constraints that would be put to test
when the timeout is made very long. Not to mention the usage constraints that
Ariel mentioned. It woudl be good to consider their feedback as well before
mandating.

Regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 07:16:52 -0700 (PDT)

Magnus,

Ariel had identified some real issues with raising the timeouts. Resource
constraints (Memory and CPU utilization) is another concern. When timeouts are
increased, NAT devices need to a) set aside memory for the largely unused
Zombie sessions, and, b) monitor the large number of zombie sessions
periodically for timeouts. 

Having said that, I am OK with a timeout anywhere between a minute and two
minutes.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 07:19:02 -0700 (PDT)

I understand and agree.

regards,
suresh

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 25 Apr 2006 07:20:22 -0700 (PDT)

Pyda Srisuresh wrote:

There are a number of enterprise/data-center devices that embed NAT
functioanlity within. They have resource constraints that would be put to test
when the timeout is made very long. Not to mention the usage constraints that
Ariel mentioned. It woudl be good to consider their feedback as well before
mandating.
This make me question the limitation of the caveat of removing mapping 
for request response protocols to below 1024. I think this caveat is 
reasonable to apply to any registered protocol with this behavior. I 
think the important fact here is that it requires a well known port that 
can be used to identify packets as belonging to that protocol.

The potential backside of this is that applications that do use the 
registered port range for temporary and dynamic allocated ports can get 
into serious trouble. But these really should be using the dynamic range.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 25 Apr 2006 14:05:27 -0700 (PDT)

On 4/25/06 7:16 AM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:

> Ariel had identified some real issues with raising the timeouts.

We have been asking for this sort of feedback on this timer
draft-audet-nat-behave-00 that went out in July 2004 - that version of the
draft said 5 minutes. We are well past WGLC. I would be thrilled to learn
more about the issue. Could you please be more specific about the the "real
issues" are? 

However, it seems that 2 minutes would likely be acceptable to most people
on this thread. 2 minutes was used in WGLC. 2 minutes was discussed and had
support in WG meetings. I am not aware of new information that radically
changes the thoughts on this.

I suspect it may be getting very late in the process for more discussion of
this.

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 17:58:04 -0700 (PDT)

I agree, the caveat is reasonable to apply to any registered protocol with this
behavior, not just the ports in the range of 1-1023.

regards,
suresh

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 25 Apr 2006 23:46:52 -0700 (PDT)

> I agree, the caveat is reasonable to apply to any registered 
> protocol with this behavior, not just the ports in the range 
> of 1-1023.

Let me walk through a problem with this line of thinking.

You build a product which uses port UDP/1025, let's say.

In the year 2009, IANA assigns a new protocol, called JILL, to
port UDP/1025.  JILL is a strict request/response protocol.  It
is very popular.  JILL causes a lot of load on residential NATs.
JILL is an IETF standard.  

A NAT vendor -- perhaps even a big one -- decides that traffic
running on UDP/1025 must be JILL traffic.  Because, after all,
it's running on the port that IANA assigned to JILL.  Thus,
that NAT vendor will ship NATs with a default configuration 
which closes down the NAT binding immediately after receipt
of a UDP response packet.

Your product, that you wrote in 2006, now ceases to work once
that new, BEHAVE-compliant NAT, is installed.

How would we prevent this from occurring?

-d

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 26 Apr 2006 00:35:05 -0700 (PDT)

Thanks Dan,

I understand the dangers with such a behavior. I wished we would have 
been clearer on RTP port usage and really pointed to the 49152-65535 
range. So unless other have strong opinions about this lets drop this idea.

Cheers

Magnus

Dan Wing wrote:

-d

--

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 26 Apr 2006 06:13:09 -0700 (PDT)

There are two ways, I can think of, to future proofing Req-5A,

a) NAT closing down the Binding or state immediately after receipt of a UDP
response packet is a bad idea. When Req-5A is interpreted this way, there is a
danger that many of the existing request/response protocols would fail to work.
There ought to be a minimum timeout even for this subset to make NATs
deterministic. I.e., Req-5A should specify minimum timeout for the
request/response type registered ports as well - say 1 min.

b) Drop Req-5A entirely. By removing this caveat, all UDP applications will be
required to have a min. timeout of 2 mins without exception. 

I prefer option b.

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 3 May 2006 19:24:51 -0700 (PDT)

On Apr 25, 2006, at 9:13 AM, Pyda Srisuresh wrote:

3. Some UDP connections are extremely short-lived.  An example  
with port>
1024 is RADIUS, which (in some modes) performs many short exchanges.
As I have pointed out before - it is simply not true that all RADIUD  
connection are short lived - some are but not all. Furthermore, you  
are unlikely to have some very large number of radius transaction per  
second on different UDP flows through one NAT.  I'm would not be  
surprised, if there are protocol that are short lived greater than  
1024 but so far we seem to be lacking examples of them. Particularly  
ones that will generate enough connections to make a substantial  
impact on an enterprise NAT. I am beginning to think there is no real  
problem here. If there is a real problem, let's get specific about it.

---

From: "Ariel Shaqed (Scolnicov)" <[email-masked]>
Date: Wed, 3 May 2006 23:33:32 -0700 (PDT)

On Thursday 04 May 2006 03:32, Cullen Jennings wrote:
> connection are short lived - some are but not all.

As this is probably my text, I should respond.

Yes, it is true that not all RADIUS connections are short-lived -- those 
used for accounting are long-lived.  But it's also true that some RADIUS 
connections can be very short-lived.  And it is true that administrators 
generally know if they intend to use RADIUS authentication or accounting 
and accordingly the desired lifetime for RADIUS connections.

RADIUS is an example of a short-lived UDP connection.  Authentication is 
perfectly suited to RADIUS.

> Furthermore, you 

I attempted to provide this in my point #1, which got lost above.

[*Not* quoting Cullen, obviously:]

] 1. Not only the 1st NAT on the path is affected.  If an application sends 
] keepalives every 2 minutes it will not work with firewalls anywhere along 
] its path that keep a smaller timeout for UDP connections and also inspect 
] the protocol.  It is probably not very practical to hold a UDP connection 
] (i.e. its current state) open on a firewall for 5 minutes of inactivity.
] 
] Note that even 0 bits of stored state can make the difference: Consider a 
] firewall dropping all UDP connections in one direction.
] 
] It make sense to specify minimal timeouts, just not for all UDP ports.

The draft is mandating particular behaviour all along the path, not just 
along the first and last hops.  For BEHAVE to be useful it must traverse 
firewalls.  Or rather, for BEHAVE-compliant apps to be useful, they must 
traverse firewalls.

And in my point #2:

] 2. The above, when the firewall is NATting its internal domain.

For example.  You have a firewall internally in your domain.  Every host 
authenticates with RADIUS.  The RADIUS server is on one side.  The hosts 
are on the other.  At 08:00 every host starts several UDP flows for each 
of several applications.  As an administrator, draft-ietf-behave-nat-udp 
has just decided for you you cannot NAT the protected hosts' domain.

-- 
Ariel.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 4 May 2006 05:28:42 -0700 (PDT)

On May 4, 2006, at 2:37 AM, Ariel Shaqed (Scolnicov) wrote:

Yes, it is true that not all RADIUS connections are short-lived --  
those
used for accounting are long-lived.  But it's also true that some  
RADIUS
connections can be very short-lived.  And it is true that  
administrators
generally know if they intend to use RADIUS authentication or  
accounting
and accordingly the desired lifetime for RADIUS connections.
OK - we are in agreement on this then.  The key point here is it is  
something the administrator would know and the vendor of the NAT  
can't know. I never have any objections to the administrator being  
able to configure the policy of firewall in any way they want.

---

From: "Ariel Shaqed (Scolnicov)" <[email-masked]>
Date: Thu, 4 May 2006 05:42:46 -0700 (PDT)

> able to configure the policy of firewall in any way they want.

Obviously the administrator can make this decision.  Equally obviously, 
having made this decision (very possibly in the past), BEHAVE-compliant 
apps cannot work.  This is not a decision on the level of disconnecting 
the machine, it is a valid configuration decision.

BEHAVE is specifying behaviour for apps, therefore it is specifying the 
same thing for devices along the way.  It is doing this for all ports.

-- 
Ariel Scolnicov.