Subject: [midcom] Comments on draft-stiemerling-midcom-semantics-02.txt: Session/Pe er Identification

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 24 Sep 2002 10:10:58 -0400

This is a series of notes on the content of
draft-stiemerling-midcom-semantics-01.txt.  This note discusses the need for
content in each message which identifies the sender and possibly the session
with which the message is associated.

I'll deal with the session identifier first.  The first paragraph of section
2.2 of the draft says that:
 "Both agent and middlebox may participate in several sessions at the same
time."

As I argue in draft-taylor-midcom-semgen-00.txt, this means at the very
least that every message must identify the sender, so that the receiver can
associate it with the right session.  Thus every request from the agent must
contain the agent identifier, and every response and notification from the
middlebox must contain the middlebox identifier, as one of its parameters.

Does this identification have to go so far as to require an authentication
token in every message?

Aside from this general question, I believe it would make sense for the
middlebox to authenticate itself in a Session Establishment reply in the
failure case as well as in the success case, to forestall a
man-in-the-middle DOS attack based on spurious rejection.

Tom Taylor
[email-masked]
Ph. +1 613 736 0961 (ESN 396 1490)

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 25 Sep 2002 10:20:16 +0200

Tom,

Thank you for commenting! Please see comments inline.

    Juergen

> middlebox must contain the middlebox identifier, as one of its parameters.

I agree. An identifier should be explicitly mentioned in the semantics
specification.

However, it does not necessarily need to be an agent identifier and a
middlebox idenitfier. A session identifier would sufficiently serve the
same prupose.

Furthermore, when discussing this in the semantics draft, we should mention
that session/agent/middlebox identifiers are already there for almost any selected
underlying communication channel. It certainly is there already when encryption
or other security functions are applied, and enven if not, most time IP address
and port number can serve this purpose.

> Does this identification have to go so far as to require an authentication

It may. The semantics document says that you may extend each transaction.
However, I don't think it is required. Authenticating once and setting
up a secure channel is already sufficient.

> man-in-the-middle DOS attack based on spurious rejection.

Interesting point. I agree on the advantage concerning the DOS attck
against the client, but I am not sure whether or not this increases the
impact of potential attacks against the middlebox.

> Ph. +1 613 736 0961 (ESN 396 1490)

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