Re: [Isms] wg last call followup - e-mail address

["tom.petch" <cfinss at dial.pipex.com>]

----- Original Message -----
From: "Juergen Schoenwaelder" <j.schoenwaelder at jacobs-university.de>
To: "Wes Hardaker" <wjhns1 at hardakers.net>
Cc: "tom.petch" <cfinss at dial.pipex.com>; <isms at ietf.org>; "Jeffrey Hutzelman"
<jhutz at cmu.edu>
Sent: Tuesday, March 03, 2009 9:37 AM
Subject: Re: [Isms] wg last call followup - e-mail address


> On Mon, Mar 02, 2009 at 11:55:50AM -0800, Wes Hardaker wrote:
> > >>>>> On Sun, 1 Mar 2009 21:04:05 +0100, "tom.petch" <cfinss at dial.pipex.com>
said:
> >
> > tp> In particular, it creates the 'Pasi problem', Command Generator
> > tp> sends a Request with securityName of Alice, gets a Reponse with
> > tp> securityName of Bob.
> >
> > No!  That never happens.  A CG that opens a request with a securityName
> > of "Alice" but a transport address of "bob at example.com" will get back a
> > securityName of "Alice", ***NOT*** Bob.
>
> Wes or DBH, can you point to the exact place in the IDs where this is
> described?
>
By way of contrast, I can point to the logic that says it does, based on my
understanding of the wording in the current drafts (either or both of which
could be wrong).  And I see a post by Pasi - later echoed by dbh - listing this
precise occurrent which reassures me that my reading, sadly, is correct. AFAICT
the wording came from Wes and has been accurately incorporated by David into the
I-D.

But it would be really really helpful if we had consensus on whether this is
acceptable or not.  Wes is the first to say not, Pasi didn't, I sat on the
fence.  If it is unacceptable, I can produce any number of EOPs that fix it, but
I think that producing EOPs and then having to reverse engineer the design and
then to speculate on the requirements is one reason why I am disappointed with
progress.  But you know that:-)  So let's have a design and then the EOPs and a
requirement as well would be lovely.

> We need to move this discussion to the concrete text in the documents.
> If we find text that handles this, we are done and can close this
> technical issue. If not, we hopefully get closer to know what text
> needs to be added where.
>
> So far I understand:
>
> - There should be a better motivation why user at host addresses are
>   supported (to make NOs work better).
>

Yes please, a requirement, in -tmsm (yes, really).   My less facetious take is

"The transportAddress, as passed by the application may take the form
user at example.com:port
The 'user' part may be used as a user address to establish a transport and then
be used by the remote engine as securityName.  The local engine still uses
securityName; two names are now in use, one for the local engine and the other
for the remote engine.

The use case for this is when, as with Notifications, the access control check
is performed in the local engine, using the local securityName, as opposed to a
Command Responder when the access control check is performed in the remote
engine, using the name supplied as part of the transportAddress and associated
security credentials."

I do not think that I have grasped the point of this yet; I well know the
Notification problem but how does this solve it?  securityName is never
authenticated so is this a solution?

> - We need to make sure that the EoP provide a consistent securityName
>   for SNMP applications using this feature.
>
> Can we please sort this out quickly?

Wish we could but be aware Juergen that I have a further stack of comments in
this area, since e-mail format (yes Jeff, I know this is not e-mail:-) addresses
have been added.  The EOPs do some odd things and I think that they need
clarifying or changing or both.  But these are the big two, how and why, and if
we agree on them, then the rest becomes clearer for me.

The others mostly revolve around transport addresses, when the user@ is or is
not there and what then happens

Pushing out another I-D before the deadline is likely, IMHO, to delay things.


Tom Petch

>
> /js
>