Subject: [i2rs] Stephen Farrell's Discuss on draft-ietf-i2rs-pub-sub-requirements-06: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 03 May 2016 17:23:07 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-pub-sub-requirements-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have what I hope are two very easily sorted things that
I'd like to chat about:

(1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why
would we ever have a pub/sub service whose subscribers can
pretend to be the service?

(2) Don't you need a statement somewhere that commensurate
security needs to be provided for pushed notifications as
was used for the original subscription? That might be a
little hard to phrase correctly but I hope we agree that
the notifications ought not be significantly less secure
than the subscription.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I wondered if this was maybe of interest to more than
just i2rs, and if so, whether any effort had been made to
try figure out if these requirements work for folks who
don't care about i2rs? It'd seem a shame to work on this
but stop one step short of being appropriately general.
(But you probably already checked that I guess.)

- 4.2.2, last para: The MUST here seems like it may be
quite onerous, in general. Did someone think all of that
through? For example, what if the reason for declining is
that the Subscriber doesn't have sufficient privilege?
Saying what privilege is needed would be a breach of
least-privilege. Transient errors may also make this very
hard to do well. I'd suggest s/MUST/MAY/ and to also turn
the information returned into a hint and not a promise.

- 4.2.5, para 1: saying there "MUST be mutual
authentication" is odd - the usual terms would be "MUST
implement" or "MUST use" which of those does "MUST be"
mean?

- 4.2.8: when you say fetch... by whom? Is there an
implicit requirement in the title of the subsection?

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 May 2016 17:45:50 +0000

Hi Stephen,

> Stephen Farrell, May 03, 2016 8:23 PM
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> I have what I hope are two very easily sorted things that I'd like to chat about:
> 
> (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we ever have a
> pub/sub service whose subscribers can pretend to be the service?

I am not sure I understand.  The Subscription Service is located on the Publisher.  Having the Publisher and Subscriber mutually authenticate each other makes sense.

If you mean something else and you are wondering if whether a Subscriber can also be a Publisher for the information it receives, yes it can.  Having a collector/controller as a middle-man is a very valid implementation.  But there is nothing which binds such independent subscriptions together.
 
> (2) Don't you need a statement somewhere that commensurate security needs
> to be provided for pushed notifications as was used for the original subscription?
> That might be a little hard to phrase correctly but I hope we agree that the
> notifications ought not be significantly less secure than the subscription.

We had some interactions with Ben Campbell on this topic.    In general we are doing our best to decouple the subscription establishment and maintenance from the underlying transport options.  This is because there are implementations (for example wholly within an MSDC) which don't require payload encryption.  Still most implementations should have transport encryption.  So after several interactions with Ben, the text leading off Section 4.2.5 now reads:

   Some uses of this Subscription Service will push privacy-sensitive
   updates and metadata.  Good deployment practices will bind this
   generated information within secure, encrypted transport layer
   mechanisms.  For example if NETCONF is used as transport, then
   [RFC5539] would be a valid option to secure the transported
   information.  The Subscription Service can also be used with emerging
   deployment contexts as well.  As an example, deployments based on
   [i2rs-usecase] can apply these requirements in conjunction with those
   documented within [i2rs-protocol-security] to secure ephemeral state
   information being pushed from a Network Element.

Does this hit your objective? 

Eric

> - I wondered if this was maybe of interest to more than just i2rs, and if so,
> whether any effort had been made to try figure out if these requirements work
> for folks who don't care about i2rs? It'd seem a shame to work on this but stop
> one step short of being appropriately general.
> - 4.2.2, last para: The MUST here seems like it may be quite onerous, in general.
> Did someone think all of that through? For example, what if the reason for
> declining is that the Subscriber doesn't have sufficient privilege?
> Saying what privilege is needed would be a breach of least-privilege. Transient
> errors may also make this very hard to do well. I'd suggest s/MUST/MAY/ and to
> also turn the information returned into a hint and not a promise.
> 
> - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd - the usual
> terms would be "MUST implement" or "MUST use" which of those does "MUST
> be"
> mean?
> 
> - 4.2.8: when you say fetch... by whom? Is there an implicit requirement in the
> title of the subsection?
> 
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 19:24:23 +0100

Hiya,

On 17/05/16 18:45, Eric Voit (evoit) wrote:
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> DISCUSS: 
I have what I hope are two very easily sorted things that I'd like to
chat about:
>> (1) 4.2.5, para2: 

It's para 3 now. Not sure if that changed in this rev or if
I goofed. If the latter, apologies;-)

>> Hang on - this is 2016 isn't it? :-) Why would we
>> ever have a pub/sub service whose subscribers can pretend to be the
>> service?
> 
> I am not sure I understand.  The Subscription Service is located on
> the Publisher.  Having the Publisher and Subscriber mutually
> authenticate each other makes sense.
> 
> If you mean something else and you are wondering if whether a
> Subscriber can also be a Publisher for the information it receives,
> yes it can.  Having a collector/controller as a middle-man is a very
> valid implementation.  But there is nothing which binds such
> independent subscriptions together.

The problem is that the text says "it SHOULD be possible to provide
   cryptographic authentication in such a way that no Subscriber can
   pose as the original Subscription Service"

I see no reason for that SHOULD. The implication I take from it
is that someone wants to use purely symmetric keying which seems
pretty odd. I'd say better text would be to say that "Subscribers
MUST NOT be able to pose as the original Subscription Service"
maybe.

> 
>> (2) Don't you need a statement somewhere that commensurate security
>> needs to be provided for pushed notifications as was used for the
>> original subscription? That might be a little hard to phrase
>> correctly but I hope we agree that the notifications ought not be
>> significantly less secure than the subscription.
> 
> We had some interactions with Ben Campbell on this topic.    In
> general we are doing our best to decouple the subscription
> establishment and maintenance from the underlying transport options.
> This is because there are implementations (for example wholly within
> an MSDC) which don't require payload encryption.  Still most
> implementations should have transport encryption.  So after several
> interactions with Ben, the text leading off Section 4.2.5 now reads:
> 
> information.  The Subscription Service can also be used with
> emerging deployment contexts as well.  As an example, deployments
> based on [i2rs-usecase] can apply these requirements in conjunction
> with those documented within [i2rs-protocol-security] to secure
> ephemeral state information being pushed from a Network Element.
> 

Not quite, though it is related.

If you added "Commensurate strength security mechanisms MUST
be defined (and SHOULD be used) for all of the stages of
the pub/sub process, for example using the same algorithms
and endpoints for keying for both subscription and publication
stages would seem advisable."

The thing to avoid is e.g. using some really strong mechanism
for the subscription but something much weaker or with worse
endpoints for the publication (or vice versa).

Sorry if that wording is a bit vague, I didn't re-read the
entire doc to get the context right.

Cheers,
S.

- I wondered if this was maybe of interest to more than just i2rs, and
if so,
>> whether any effort had been made to try figure out if these
>> requirements work for folks who don't care about i2rs? It'd seem a
>> shame to work on this but stop one step short of being
>> appropriately general. (But you probably already checked that I
>> guess.)
>> 
>> - 4.2.2, last para: The MUST here seems like it may be quite
>> onerous, in general. Did someone think all of that through? For
>> example, what if the reason for declining is that the Subscriber
>> doesn't have sufficient privilege? Saying what privilege is needed
>> would be a breach of least-privilege. Transient errors may also
>> make this very hard to do well. I'd suggest s/MUST/MAY/ and to also
>> turn the information returned into a hint and not a promise.
>> 
>> - 4.2.5, para 1: saying there "MUST be mutual authentication" is
>> odd - the usual terms would be "MUST implement" or "MUST use" which
>> of those does "MUST be" mean?
>> 
>> - 4.2.8: when you say fetch... by whom? Is there an implicit
>> requirement in the title of the subsection?
>> 
>> 
>> _______________________________________________ i2rs mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 May 2016 18:32:26 +0000

Hi Stephen,

And some thoughts on your comments too...

> From: Eric Voit, May 17, 2016 1:46 PM
> 
> Hi Stephen,
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > (1) 4.2.5, para2: Hang on - this is 2016 isn't it? :-) Why would we
> > ever have a pub/sub service whose subscribers can pretend to be the service?
> 
> I am not sure I understand.  The Subscription Service is located on the Publisher.
> Having the Publisher and Subscriber mutually authenticate each other makes
> sense.
> 
> If you mean something else and you are wondering if whether a Subscriber can
> also be a Publisher for the information it receives, yes it can.  Having a
> collector/controller as a middle-man is a very valid implementation.  But there is
> nothing which binds such independent subscriptions together.
> 
> > needs to be provided for pushed notifications as was used for the original
> subscription?
> > That might be a little hard to phrase correctly but I hope we agree
> > that the notifications ought not be significantly less secure than the
> subscription.
> 
> We had some interactions with Ben Campbell on this topic.    In general we are
> doing our best to decouple the subscription establishment and maintenance
> from the underlying transport options.  This is because there are
> implementations (for example wholly within an MSDC) which don't require
> payload encryption.  Still most implementations should have transport
> encryption.  So after several interactions with Ben, the text leading off Section
> 4.2.5 now reads:
> 
> > if so, whether any effort had been made to try figure out if these
> > shame to work on this but stop one step short of being appropriately general.

Yes, we have attempted to aggregate requirements from other sources.   At the beginning there were discussions across I2RS, NETCONF, NETMOD WGs and Ops and Routing ADs to arrange for general applicability.

> > Did someone think all of that through? For example, what if the reason
> > for declining is that the Subscriber doesn't have sufficient privilege?
> > Saying what privilege is needed would be a breach of least-privilege.
> > Transient errors may also make this very hard to do well. I'd suggest
> > s/MUST/MAY/ and to also turn the information returned into a hint and not a
> promise.

Thanks, you make good points...

(1) Changing text to explicitly show that these are hints.  
(2) Changing text to SHOULD.
(3) If the subscriber doesn't have privilege, then the target YANG path would not exist (or be found).   Which would be a normal error, not a constrained resource error.  And this requirement was aimed at resource constraints.   Which means the text needs to be tweaked. 

To meet these 3 points, how about the text: "In cases where a Subscription Request cannot be fulfilled due to insufficient platform resources, the Subscription Service SHOULD include within its decline hints on criteria that would have been acceptable when the Subscription Request was made."

> > - 4.2.5, para 1: saying there "MUST be mutual authentication" is odd -
> > the usual terms would be "MUST implement" or "MUST use" which of those
> > does "MUST be"
> > mean?

MUST use.  Will change text.   

> > requirement in the title of the subsection?

What is implicit is that some mechanism to meet operational requirements of this section should exist.   The entity doing the fetching could be an NMS.

Thanks,
Eric

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 19:34:53 +0100

> And some thoughts on your comments too...

Those're all good.
Cheers,
S

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 May 2016 19:10:38 +0000

+ more

> From: Stephen Farrell, May 17, 2016 2:24 PM
> 
> 
> Hiya,
> 

Yes.   That is what caught me too.   I was answering for Paragraph 2.
 
> MUST NOT be able to pose as the original Subscription Service"

Your text is better.   Changed.

> entire doc to get the context right.

I see what you are getting at now.   How about the requirement text:

"For any encrypted information exchanges, commensurate strength security mechanisms MUST be available and SHOULD be used.  This includes all stages of the Subscription and update push process."

Thanks,
Eric

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 20:22:07 +0100

Hiya,

> + more

Looks like we're sorted. Just shoot out a rev with those
changes and I'll clear,

Thanks,
S.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 17 May 2016 19:30:16 +0000

v09 posted

This version should have all discussed changes across all reviewers.

Eric

> > "For any encrypted information exchanges, commensurate strength security
> mechanisms MUST be available and SHOULD be used.  This includes all stages of
> the Subscription and update push process."
> >
> > Thanks,
> > Eric
> >
> >
> >
> >> Cheers,
> >> S.
> >>
> >>>
> >>> Eric
> >>>
> >>>>