Subject: [Isms] issue #12: fate sharing

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Dec 2009 11:52:40 +0100

Hi,

at the last IETF meeting, we did run out of time on issue #12. Here
is the content of Wes' slide:

--

#12: Fate Sharing

Currently:

  - Can create TLSTM-MIB entries in advance of TARGET-MIB entries
    being created
  - When TARGET-MIB entries are deleted, corresponding TLSTM-MIB
    entries are deleted

Juergen finds this inconsistent.
  - Second bullet decided in previous WG

Proposal: leave as is

--

A more detailed explanation: The tlstmParamsEntry, which is
conceptually a (D)TLS specific extension of the SNMP-TARGET-MIB's
snmpTargetParamsTable, currently has has the following text in the
description of tlstmParamsRowStatus:

        If this row is deleted it has no effect on the corresponding
        row in the targetParamsTable.

        If the corresponding row in the targetParamsTable is deleted
        then this row must be automatically removed.

I (speaking as technical contributor) find this second sentence
somewhat surprising for essentially two reasons:

- First, we specify here something that at the end affects the
  implementation of targetParamsTable, which may or may not be our
  business (but I guess is unavoidable for behaviours like this).

- Second, while we allow to provision entries in tlstmParamsEntry for
  later use (once targetParamsTable entries are created), we forbid to
  reuse those provisioned entries once a targetParamsTable using it
  gets removed - which can be considered somewhat inconsistent.

As a chair, I do not have a strong opinion about this and by default
we will continue with the text currently in the document. If WG
members support a change of the text (i.e. removal of the second
quoted sentence), then please speak up now. Silence will be read as
agreement to the current text.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 16 Dec 2009 05:39:48 -0800

>>>>> On Wed, 16 Dec 2009 11:52:40 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> at the last IETF meeting, we did run out of time on issue #12. Here
JS> is the content of Wes' slide:

Thanks for the nicely done summary of the issue Jurgen.  I'd like to
note that if WG members want to comment on it, please do so within the
next 2 weeks as I intend to publish a new draft soon to address David's
comments.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Wed, 16 Dec 2009 11:14:31 -0500

Hi,

In SSHTM (and in TLSTM), it is possible to attempt to set up entries
in advance, creating the tunnels for expected communication. This was
deliberate and had consensus of the WG for SSHTM work. I think Eliot
was the person who first championed this approach. 

I think the idea was to support one channel that could support both
request/response traffic and notification traffic. I am not sure
whether that is still something that can be suppoorted, given the way
SSHTM has been written, and given the assumptions about
implied-authentication of the sender for notifications.

>   - Can create TLSTM-MIB entries in advance of TARGET-MIB entries

but the second point would potentially cause a problem, I think.
>   - When TARGET-MIB entries are deleted, corresponding TLSTM-MIB

It may not be a problem, if the only TLSTM-MIB entries that are
associated with TARGET-MIB are for notifications. You might want to be
able to set up a channel in advance to receive notifications. 

If these will be fate shared, then the text should be very clear to
operators that they MUST fill in the TARGET-MIB first before they do
the TLSTM-MIB. The correllary to the point above is that the TLSTM-MIB
entries should not be instantiated if the corresponding TARGET-MIB
entries don't exist. What happens if the TARGET-MIB entry becomes
inactive? Does the corresponding TLSTM-MIB entry become inactive?

I personally don't care whether pre-creation is supported. I just
wanted to explain some of the thinking behind the original decision,
whiuch could be impacted by the fate-sharing decision.

I will point out that I don't think SSHTM has this fate-sharing
restriction, and would tend to favor consistency across models because
of the impact to operators of having different approaches to
configuration rules in different models.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, December 16, 2009 5:53 AM
> To: [email-masked]
> Subject: [Isms] issue #12: fate sharing
> 
> Hi,
> 
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Dec 2009 08:26:33 -0800

>>>>> On Wed, 16 Dec 2009 11:14:31 -0500, "David Harrington" <[email-masked]> said:

DH> In SSHTM (and in TLSTM), it is possible to attempt to set up entries
DH> in advance, creating the tunnels for expected communication. This was
DH> deliberate and had consensus of the WG for SSHTM work. I think Eliot
DH> was the person who first championed this approach. 

Eliot wanted to design something to allow for a "callhome" approach.
The goal was to let something like a Command Responder call home to a
Command Generator and wait for incoming traffic.  IE, the CR became the
SSH client and the CG the SSH server.  Nothing that has been done has
necessarily prohibited that approach from happening, but internally all
the SNMP stacks don't act that way at all.  I'm not saying they couldn't
though.

>> - Can create TLSTM-MIB entries in advance of TARGET-MIB entries

You're implying there that creating the TLSTM-MIB entry opens the
connection; it does not.  The TARGET-MIB is still the source of the
configuration for who to talk with.  Any support for call-home type
approaches would need to still use the TARGET-MIB as the source of data
to make the connection with and is beyond the scope of this work.  We
don't, however, add anything that prevents this future work from
happening (and in fact, by adding the configuration objects we have
we're helping support it).

Based on the rest of your text, I think you were misunderstanding the
discussion surrounding pre-creation and fate-sharing.  The discussion
was only talking about the fate sharing between the MIB tables and had
nothing to do with advanced connection establishment (which, as I said,
is out of scope as it should be done in a generic fashion in 'some other
MIB module').
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Dec 2009 13:36:06 -0500

Hi,

I assume the information in the tlstmParamsTable and the
tlstmAddrTable must be manually configured by an administrator. We
usually expect such information to be persistent across reboots. I
didn't see text in the MIB that said this.

Now back to paragraph 1 of my response. If this is admin-configured,
we probably do not want to automatically delete the configuration
information and force the admin to re-enter the info. 

Is this a potential scenario? An admin decides to delete and re-enter
a target-mib entry, possibly because he entered the info incorrectly
in the first place. But he did enter the corresponding info in
tlstmParamsTable correctly. If he deletes the incorrect target-mib
info, will the tlstmParams data be automatically discarded, forcing
the operator to re-enter the information?

tlstmParamsRowStatus says "Until instances of all corresponding
columns are appropriately configured, the value of the corresponding
instance of the         tlstmParamsRowStatus column is 'notReady'."
There are columns in the TARGET-MIB that could be interpreted as being
"corresponding" columns. I think the text here needs to be more
explicit about what the corresponding columns are.

If columns in this table fate-share with columns in TARGET-MIB when
columns there are deleted, then the required corresponding columns for
creation should probably include the corresponding target-mib columns.

dbh

> From: Wes Hardaker [mailto:[email-masked]] 
> Sent: Wednesday, December 30, 2009 11:27 AM
> To: David Harrington
> Cc: 'Juergen Schoenwaelder'; [email-masked]
> Subject: Re: issue #12: fate sharing
>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 30 Dec 2009 11:10:20 -0800

Hi -

> From: "David Harrington" <[email-masked]>
> To: "'Wes Hardaker'" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, December 30, 2009 10:36 AM
> Subject: Re: [Isms] issue #12: fate sharing
...
> explicit about what the corresponding columns are.

I would hope that what is intended is "this row of this table". 
...
> creation should probably include the corresponding target-mib columns.
...

Fate-sharing between tables is, in my opinion, something that should
in general be carefully avoided.  It produces too many potential surprises,
and can even provide a back-door around access control.  (should deleting
something to which one has access rights cause the deletion of something
to which one potentially has no access rights?)

Fate-sharing between tables also unnecessarily complicates implementation,
since it makes fairly strong assumptions about those tables being implemented
in such a way that the module resposible for implementing the one will have
access to the data structures of the other, potentially violating the design modularity.

Randy

---

From: "David Harrington" <[email-masked]>
Date: Wed, 30 Dec 2009 14:47:43 -0500

I also prefer to avoid fate-sharing.
If fate-sharing is supported, then I think the fate sharing for
creation and deletion should match.

Since the tables in question contain security certificate hashes, are
there any security considerations related to having orphaned entries?

dbh

> Behalf Of Randy Presuhn
> Sent: Wednesday, December 30, 2009 2:10 PM
> To: [email-masked]

---

From: "Donati Andrew-MGIA0477" <[email-masked]>
Date: Wed, 30 Dec 2009 19:01:01 -0500

Since persistence is handled by the value of StorageType in each row,
we can run into an issue where corresponding rows in each table do not
share 
the same StorageType value. For example, one can be volatile and the
other non-volatile. 

Andy Donati

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of David Harrington
> Sent: Wednesday, December 30, 2009 1:36 PM
> To: 'Wes Hardaker'
> Cc: [email-masked]

> I assume the information in the tlstmParamsTable and the
tlstmAddrTable must be
> manually configured by an administrator. We usually expect such
information
> to be persistent across reboots. I didn't see text in the MIB that
said this.

> Is this a potential scenario? An admin decides to
> delete and re-enter a target-mib entry, possibly because he entered
the info
> incorrectly in the first place. But he did enter the corresponding
info
> in tlstmParamsTable correctly. If he deletes the incorrect target-mib
info,
> will the tlstmParams data be automatically discarded, forcing the
operator
> to re-enter the information?

> There are columns in the TARGET-MIB that could be
> interpreted as being "corresponding" columns. I think the text
> here needs to be more explicit about what the corresponding columns
are.

> If columns in this table fate-share with columns in TARGET-MIB when
columns
> there are deleted, then the required corresponding columns for
creation
> should probably include the corresponding target-mib columns.

> Command Generator and wait for incoming traffic.  IE, the CR became 
> the SSH client and the CG the SSH server.  Nothing that has been done
has
> necessarily prohibited that approach from happening, but internally 
> all the SNMP stacks don't act that way at all.  I'm not saying they 
> couldn't though.
> 
> approaches would need to still use the TARGET-MIB as the source of 
> data to make the connection with and is beyond the scope of this work.
We
> nothing to do with advanced connection establishment (which, as I 
> said, is out of scope as it should be done in a generic fashion in 
> 'some other MIB module').
> --
> Wes Hardaker

---

From: "tom.petch" <[email-masked]>
Date: Thu, 31 Dec 2009 12:14:26 +0100

David

On the question of setting up in advance, that is something I have 
always wanted and seen almost as necessary for Notifications.

I would have liked the Notification Receiver to be able to to this,
since it is that engine that is keenest to make it happen and is likely
to be the one with the greatest amount of infrastructure around it
(automation, human operators ...).  And it solves the DTLS 
heartbeat (lack of) problem.

I intend to go through tlstm and see if it is possible.

On fate sharing per se, sounds like a dreadful idea, full of scope
for disasters caused by boxes doing things that humans would
never expect them to do.  There has got to be either an obvious
(to a human) link between a and b for a change to a to ripple
automatically into b or else b has got to be so obscure that a
human will never consider it.

Tom Petch