Subject: [midcom] Updated framework draft

From: "Melinda Shore" <[email-masked]>
Date: Fri, 18 May 2001 11:08:32 -0400

More comments:

section 2.9:  A policy server would not add or delete
midcom agents on a middlebox.  It would authorize or
terminate authorization for an agent, it seems to me.
All it can do is provide policy information.

5.2: I'm still not clear on where you're going (or
why) with the out-of-band agent stuff.  There were
still a lot of questions about it coming out of the
Minneapolis meeting and I'm not sure that they've
been resolved.  At this point I think it would be
useful to hear from other people who see the need
to include out-of-band agents in the framework.

6.0  Same as 2.9 - a policy server performs in an
advisory capacity only.  It can inform a middlebox
that an agent is no longer authorized, but it cannot
"delete" an agent.  It's up to the middlebox to do
that.  I'm also not comfortable with the text around
determining trust levels.  It sounds like you're
suggesting that the policy server probe the agent
and then make its own determination about to what
extent the agent can be trusted.  Is that really
what you mean?

6.1  I still don't like the appearance of AH and ESP
in the text - if nothing else, given that particular
range of options I'd personally prefer ESP for
authentication, too.  But aside from that, there are
all sorts of mechanisms that could be used to provide
authentication, integrity, and confidentiality, and
given the interest in performance I might be inclined
to put IPSec down towards the bottom of the list 
(assuming that you were planning on using IKE for SA
establishment - were you?).  In general we need to
talk about *why* various protections are required rather
than specifically what those protections would be.
For example, a consequence of not authenticating
an agent would be that an attacker could spoof the 
identity of a "legitimate" agent and open holes in
the firewall.  Another would be that it could otherwise
manipulate state on a middlebox, creating a denial-
of-service attack by closing needed pinholes or filling
up a NAT table.  A consequence of not authenticating
the middlebox to an agent is that an attacker could
pose as a middlebox and respond to NAT requests in a
manner that would divert data to the attacker.  And 
so on.  Save discussion of mechanism until we have a
basic understanding of what it is that we need to
protect against.

Also, I'm not clear why you have this section *and* a
"security considerations" section.

6.2  Establishing a transport connection only involves
authentication if you're using IPSec.  (BTW, it may
be worth tweaking the language so that it's still meaningful
if the midcom protocol runs over UDP.)  In terms of when
to register, it may be worth pointing out that when
you're using a session-oriented protocol with a NAT,
you'll need to get a NAT table mapping *prior* to
trying to establish a NATted stream, since the address
will have to be embedded in the session signaling
payload.  In the last paragraph you suggest that the
policy server tells the middlebox to deregister an agent.
Too much information!  A middlebox could deregister an
agent for a lot of reasons, policy being one of them.

12:  still really doesn't talk about the threat environment
and largely repeats what's in 6.1.  Aside from that, I
think that I'd probably add some text to the effect that
because stateful inspection firewalls and NATs require
access to data in the clear, the use of traditional
firewalls/NATs has mitigated against the use of encryption
in some environments.  Similarly, the use of stateful
inspection and rewrite NATs has prevented the use of
integrity protection on data streams expected to traverse
NATs.  By moving application state out of the middleboxes
we're allowing applications to better protect themselves
end-to-end.

Melinda

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 19 May 2001 22:57:10 -0700 (PDT)

Melinda,

I take your comments below to be largely divided into 3 areas - 
(a) Policy Server Interface (b) Security considerations, 
(c) Out-of-Path agents . I will respond to the first two areas
in this thread.

Here is my basic view of the Policy Server Interface. I will use the
following as the basis to address your concerns. These are the
same principles that drove the text in the draft as well. Hope
this will address the concerns raised by others (Eliot Lear, 
Eric Fliieshman etc.) as well.

1. An external Policy Server is not an absolute requirement on the 
   middlebox. By that I mean that Policy Server function may be 
   embedded within the middlebox.
   I.e., Agents may be pre-registered on the middlebox (or) may be
   registered on a Policy Server.
 
2. A Policy Server will have the following information concerning agents.

   Agent    | Authorization Policy   | Access (or)  | Security Profile
            |(ie, sessions for which | Connectivity |(MIDCOM Message 
            | agent is authorized)   | Profile      | level security)
   ---------|------------------------|--------------|-------------------
   Agent-1  |(<src-Addr>,<dest-Addr> |Agent Type    | Authentication, 
            | <Prot>, <Application-1>|(In-Path/OOP),| integrity and
            |                        |Accessibility,| confidentiality
            |                        |Host-auth info| requirements
   ---------|------------------------|--------------|-------------------
   Agent-2  |(<src-Addr>,<dest-Addr> |Agent Type    | Authentication, 
            | <Prot>, <Application-2>|(In-Path/OOP),| integrity and
            |                        |Accessibility,| confidentiality
            |                        |Host-auth info| requirements
   ---------|------------------------|--------------|-------------------
                        .....

3. Lastly, Policy Server may be consulted by the middlebox only during 
   agent connection setup phase(not during run time). 
   Further, when an agent is deregistered on a Policy Server (or) 
   when deemed administratively appropriate by the Policy Server, 
   the policy Server may notify the middlebox that a particular 
   MIDCOM agent is no longer authorized.

Please see my responses to your specific comments below.

> All it can do is provide policy information.

I disagree. See item (3) above.

<... stuff deleted> 

> extent the agent can be trusted.  Is that really

I dont understand where you picked up this noton that 
Policy Server is directly probing the agent. I dont 
recall ever stating this in the draft. I will be glad 
to fix any specific text that may have caused this mistaken
notion. Thanks.

Let me restate.
   - Policy Server is in the advisory capacity.
   - Policy Server is allowed to notify the middlebox to delete
     existing agents.
   - There is no direct communciation ever implied between
     the agent and the Policy Server.

> than specifically what those protections would be.

What is needed are as stated in item 2 above - Host authentication,
Message level authentication, integrity and confidentiality.

Section 6.1 addresses these requirements. Further, it identifies
known ways of addressing these requirements - (a) source-address 
based security, (b) TLS based security, (c) IPsec based security. 
Are you averse to mentioning the mechansims? (or) do you find 
the list inadequate? 

And, why do you have a problem with listing the IPsec mechanism 
upfront?

The document makes no specific recommendation of any of the 
mechansims specified.

As for the why - it is listed under the security considerations
section.

> manner that would divert data to the attacker.  And 

Well, all this is stated in the Secutities considerations
section even though, it might be hard to decipher. I do like
your text composition and will be glad to use that in the
follow-on rev. 

> basic understanding of what it is that we need to

What is the problem in stating the well-known mechanisms?
The reader can relate to it quickly. 

> "security considerations" section.
The securities consideration section addresses 
(a) "Why" on secure communication between middlebox and agent,
(b) Security vulnerability to applications being controlled
    by multiple agents.
 
> authentication if you're using IPSec.  (BTW, it may

What is a transport connection to do with IPsec? Transport
connection simply requires a host-based authentication.

> if the midcom protocol runs over UDP.)  In terms of when

The text makes no reference to TCP or UDP based connection.

> agent for a lot of reasons, policy being one of them.

Isnt that what the text says? Policy Server notifying the
middlebox is a way by which the middlebox could disconnect
an agent.

> and largely repeats what's in 6.1.  Aside from that, I

See my comments earlier.

> in some environments. 

This is nothing more than is inherently a requirement from
the middleboxes, with or without MIDCOM, right? 
I agree, it is still worthwhile to state this one more time.
 
>                       Similarly, the use of stateful
> NATs. 

Same as above.
 
>       By moving application state out of the middleboxes
This is true only when the agent is running on the end-host.

> Melinda

cheers,
suresh

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

---

From: "Melinda Shore" <[email-masked]>
Date: Sun, 20 May 2001 09:52:19 -0400

>    embedded within the middlebox.

Of course, but we need for that function to be addressed,
regardless of whether it sits on the middlebox or sits
elsewhere.  It's the same as the situation with an agent,
which may sit on the middlebox (for example, a stateful
inspection firewall is implicitly running a midcom function
between the stateful inspection element and the filtering
policy element.

We need for this to be clearer, whether it's addressed in
this document or in another.  Even if you don't accept this
in principal, for practical purposes I should point out that
it was the ADs who added the policy deliverable to our
charter, so I would guess that failing to more fully
consider the policy function will delay the approval
of the documents.

>    agent connection setup phase(not during run time). 

Not necessarily.  What is your reason for saying that?

>      the agent and the Policy Server.

Okay!  The source of the confusion is the language:
in several places you have said that the policy server,
for example, deletes agents on a middlebox.  It can't
do that.

> Message level authentication, integrity and confidentiality.

Why?  I don't get that from your document, and one thing
I know for a fact is that when a draft says "we will use
IPSec or TLS to protect our protocol" it means that they
haven't thought very hard about security issues.

> Are you averse to mentioning the mechansims? (or) do you find 

I find it inappropriate.  1) Identify the problem to be
solved, and 2) select the best mechanism.  Security mechanisms
are generally expensive and inconvenient and difficult to
do correctly.  It's important not to be cavalier about it,
especially when we're talking about a protocol that 1)
pokes holes in firewalls, and 2) tells endhosts to divert
their data streams.

> And, why do you have a problem with listing the IPsec mechanism 

Because I don't know if IPSec is the best way to 
protect the protocol that has yet to be identified
here.  There's a very good chance that it's not.

> The reader can relate to it quickly. 

But you're not talking about why you're selecting those
mechanisms.  The naive reader may be able to relate to it,
but I'm not sure that it's going to be useful to aid in
protocol selection and design.

> connection simply requires a host-based authentication.

Perhaps we need a definition of "transport" in the terminology
section so that it's clear what's meant in this section.

> The text makes no reference to TCP or UDP based connection.

Right!  And we don't want to use language that's exclusive
of UDP.

> middlebox is a way by which the middlebox could disconnect

I think you'll need to add some text in that section to
make it clear that the policy server asking the middlebox
to terminate its connection with and/or registration of
an agent is one way among many.  

> I agree, it is still worthwhile to state this one more time.

I think it's a security consideration.
 
> This is true only when the agent is running on the end-host.

Nope.  It doesn't matter where the agent is, as long as
it's able to provide sufficient information to the middlebox
to allow the middlebox to pass encrypted or integrity-
protected data.

Melinda

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 21 May 2001 09:56:41 -0700 (PDT)

> consider the policy function will delay the approval

Melinda - There is no disagreement thus far.
I do understand the need for a Policy Server and that is why we have
a dedicated section in the framework draft to address the policy Server.
 
I am OK with changing the text wherever necessary to make the draft
a better read. But, Fundamentally, there has to be a common 
understanding of what the function of a Policy Server is. It is with 
this in mind that I listed the three guiding principles (in my previous
e-mail) to state my view of the Policy Server.

> Not necessarily.  What is your reason for saying that?

Hmm.. This is perhaps the big source of confusion that needs to be 
cleared.

I believe, the policy server is a repertoire of information pertaining to 
various agents (that can connect to middlebox). The Policy server has no
knowledge of middlebox service and as such cannot help a middlebox with
any of the run-time policy decisions pertaining to middlebox resource
control.

I would like to understand why you said "Not necessarily".
> for example, deletes agents on a middlebox.  It can't

In that case, I will be glad to fix the text in all the places 
where it says the above. What I really meant to say was that a Policy
Server may notify the middlebox to delete existing agents.

> haven't thought very hard about security issues.

Isnt this mentioned in the first paragraph of section 6.1?
Let me try and expand on the text further.
 
> do correctly.  It's important not to be cavalier about it,

Melinda - tell me a framework document that discusses security and
does not mention IPsec as an option? Trust and Security are important
to ensure when an external agent is controlling middlebox resources. 
The agent has to be trusted, just as much as the transport path in 
which the communication takes place. As such, the transport path
has to be secured, even if the agent is trusted. Ipsec and TLS are 
two most common mechansims used for the security of transport path. 

Simple Source-address based security may be permitted in a trusted
domain and should be limited only to the most trusted hosts.

As for problem identification - I believe, the text in section 6.1
does that. But, I will try to expand on the text to make it clearer.
Thanks for your feedback.

> pokes holes in firewalls, and 2) tells endhosts to divert
                                   ^^^^^^^^^^^^^^^^^^^^^^^^
> ^^^^^^^^^^^^^^^^^^^

MIDCOM protocol only tells the middlebox (not end-hosts) to divert
the data streams. 

> here.  There's a very good chance that it's not.

I believe, the last pragraph in section 6.1 implies IPsec and TLS
as the only mechanisms to authenticate. Sorry, that was not the intent.
I will remove the text in parenthesis. However, nowhere in the 
document is it said that IPsec is the best way to protect messages.
   
> protocol selection and design.
See my previous responses.

> section so that it's clear what's meant in this section.

MIDCOM transport connection establishment simply requires host-based
authentication.

> an agent is one way among many.  

OK.

> I think it's a security consideration.
OK.
  
> to allow the middlebox to pass encrypted or integrity-
That assumes that agent will have the same end-to-end ability as 
the end-host to interpret encrypted and integrity protected
data, right?
 
> Melinda
Thanks.

cheers,
suresh

---

From: "Melinda Shore" <[email-masked]>
Date: Mon, 21 May 2001 13:29:52 -0400

> any of the run-time policy decisions pertaining to middlebox resource

All the policy server can do is manage and distribute
policy data.  That data could potentially be pretty 
much anything, and since we haven't yet talked much about
what kind of data would be needed to support firewall
and NAT services I think it's premature to say that
it will never be consulted during a middlebox transaction.

> two most common mechansims used for the security of transport path. 

Why specifically does it have to be trusted?  What are
the threats?  How do we increase the likelihood that we
will be selecting the correct mechanism?  Why would IPSec
be a better choice for a midcom protocol than, say, Kerberos?

> MIDCOM protocol only tells the middlebox (not end-hosts) to divert

Picture this:  I am an attacker posing as a middlebox.
A SIP proxy server behind a NAT is functioning as a 
midcom agent, and I spoof my identity so that it
registers with me.  It then sends a request for a
NAT table mapping for an RTP port, and I send it back
the address of my handy-dandy data recorder.  The
SIP proxy server has no reason to think that there's
anything wrong with the transaction and it puts the 
bogus address in the SDP for the INVITE.  The call is
established and the other party then duly ships off its 
outgoing RTP to my recorder.

> MIDCOM transport connection establishment simply requires host-based

Not necessarily.  

> the end-host to interpret encrypted and integrity protected

No, that's a different question.  By removing the need
for the middlebox inspect or manipulate data as they traverse
it, we're allowing end-to-end security mechanisms to be
used where it hasn't been possible in the past.  The agent
is involved only in that it's asking the middlebox to open
holes, install NAT table entries, etc.

Melinda