Subject: RE: [midcom] Semantics Of "Session"

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 2 Aug 2002 13:31:48 -0400

Just on your very last point, you go beyond Christian.  The framework shows
very clearly a formal start of session and end of session exchange.  I see
no choice but to indicate such exchanges at the semantic level, however they
are realized in practice.  But we can omit the session identifier from all
other information exchanges.

-----Original Message-----
From: Aoun, Cedric [GOLF:MA01:EXCH] 
Sent: Friday, August 02, 2002 1:20 PM
To: 'Christian Huitema'; Scott Brim; [email-masked]
Subject: RE: [midcom] Semantics Of "Session"

I still remember our bar BOF and small meeting that we had in London last
year in August, we're we all rejected the notion of a "session" as it meant
zillions of things. we all agreed that the notion of session was more a
notion of an association relation based on trust and no more (i.e. it is an
SA or something similar).
The establishment of the association starts with the authorization policy
provisioning matching the authorized agents. This should be augmented by
having an SA between the Middlebox and the Midcom agent.
I agree with Christian, the protocol semantics should not include any form
of session information. 
Cedric 
-----Original Message----- 
From: Christian Huitema [mailto:[email-masked]] 
Sent: 02 August 2002 18:03 
To: Scott Brim; [email-masked] 
Subject: RE: [midcom] Semantics Of "Session" 

> From: Scott Brim [mailto:[email-masked]] 
> On Fri, Aug 02, 2002 11:32:35AM -0400, Tom-PT Taylor allegedly wrote: 
> > Is there any semantic content to a MIDCOM session, then, 
> except as a policy 
> > context for the Middlebox to use when evaluating requests 
> from the Agent?  
> 
> During your presentation, and occasionally in others, I would 
> ask myself 
> "what's a session?".  There are no semantics that need a session 
> concept.  However there needs to be shared state on both 
> ends, including 
> a cookie which can be assigned to rules and used arbitrarily.  We can 
> conceive of uses for it today (like 'I'm done with everything with 
> cookie xyzzy'), and there may be more in the future. 
I don't think we need any concept of a midcom session, and specifically 
any concept tying the state of the "session" to the validity of rules 
installed in the meddlebox. A session might be useful as a form of 
transport & security shortcut, i.e. authenticate the requestor once per 
session instead of once per transaction, but that is about the only 
thing that is really needed. Specifically, an agent must be able to 
install a rule that is supposed to be valid for some lifetime, go off 
the network, and be confident that the rule is operative. 
-- Christian Huitema 
_______________________________________________ 
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: Scott Brim <[email-masked]>
Date: Fri, 2 Aug 2002 13:40:04 -0400

> other information exchanges.

The Framework was not completely finished imho.  There were several
ideas in it which hadn't been completely cleaned up.  Personally I
didn't push for doing so because I thought the requirements were more
important, the framework was non-normative, and we wanted to get to the
actual protocol.  So I would not take the Framework as gospel.

Personally I like the "session" identifier, but I wouldn't call it that.

...Scott

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 07 Aug 2002 00:59:28 +0200

Christian and Cedric,

> other information exchanges.

In general we could omit session control in the semantics discussion.
However, there are some aspects that can nicely be tied to session:

  - the mutual authentication of agent and middlebox,
  - the agreement on an encryption method,
  - the exchange of capabilities,
  - the authorization check for an agent.

All these things can be handled independent of a sessions, but it appears
to be reasonable and practical to tie some or all of them to the concept
of a session. This allows us to have all of them just once per session
and not once per message.

Therefore, it makes sense to discuss sessions in the semantics.
Still, there is no need to talk about session identifiers in the
semantics specification.

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de