Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and server-model-06 available - All Open issues closed

From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
Date: Tue, 3 Mar 2015 22:16:21 +0000

Dear NETCONF WG,

we hereby issue a WG Last Call for 2 weeks for the drafts below:

https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
https://tools.ietf.org/html/draft-ietf-netconf-server-model-06

Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT.

Call Home and Server Model drafts are planned to publish as standard track documents.

Please state explicitly that you have read/reviewed and whether you support the publication of the drafts.
Please indicate also if you plan to implement or have already implementation experience with the these drafts.

Thank you,
Mehmet and Mahesh

From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Thursday, February 05, 2015 5:30 PM
To: [email-masked]
Subject: [Netconf] call-home-04 and server-model-06 available - All Open issues closed

All,

all call-home issues have been solved and there are 3 issues for server-model draft in REVIEW state.
See https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed and
https://github.com/netconf-wg/server-model/issues.

Please check the provided solutions in the updated drafts and comment before we go to WGLC after the end of Restconf LC.

https://tools.ietf.org/html/draft-ietf-netconf-call-home-04
https://tools.ietf.org/html/draft-ietf-netconf-server-model-06

Regards,
Mehmet

---

From: t.petch <[email-masked]>
Date: Wed, 4 Mar 2015 15:11:17 +0000

I have read call-home and find it problematic.  I am reminded of Alan
Luchuk's comments of almost a year ago when it was still reverse-ssh.  I
find it unclear, hard to understand, confusing in places without knowing
things that are unsaid.  The improvements made to the text then have
mostly disappeared with a change of scope.

I think that the scope of the document - NETCONF, RESTCONF, TLS, SSH,
certificates, public keys - is right but that does not mean it is always
possible to cover all the cases in a single sentence and that more
fleshing out is needed.  Thus repeatedly the use of NETCONF/RESTCONF
allows combinations that I suspect are invalid, such as RESTCONF over
SSH or NETCONF using the port assigned to RESTCONF.

What then is the scope?  For most of the I-D, I infer NETCONF with SSH
and TLS, RESTCONF (which I am not competent to review) with TLS, TLS
with certificates, SSH with public keys.  But then I see at the end of
s.3
" However, to use X.509 certificates with SSH, ..."
so it looks like SSH with certificates is there too.  How about TLS with
something else?  We did debate this at length for another I-D and slowly
converged on X.509 certificates only.  Is this true here?  If so, it
needs saying up front IMO.

SSH makes a rather sudden appearance in the Introduction (lack of scope
again); I think it should be in the Abstract e.g.

NEW (In both Abstract and Introduction)

 This document presents NETCONF Call Home and RESTCONF Call Home, which
enable a NETCONF or RESTCONF server to initiate a
   secure connection to a NETCONF or RESTCONF client respectively.  The
RESTCONFconnection is over TLS, the NETCONF over TLS or SSH. "

[Note that the current use of respectively is wrong IMO; you have 'A and
B', but no 'C and D' to be respective to.]

1
"preserve the client/server roles of underlying transport, as when
compared"

Well no, the whole point is to reverse the transport.  Of course, if TCP
is not a transport, well, I part company there.  It is argued just what
TLS is, transport or not, with TCPM and TLS WGs apt to part company.  SO

" preserve the client/server roles of underlying secure connection, as
when
compared"

I would add at the end of this paragraph
"References to SSH in this document are only applicable to NETCONF"

(as well as fleshing this out later).

1.3
A year ago, we had

" these techniques MUST only be used for NETCONF Call Home"

which Benoit said was impossible.  Now we have 'SHOULD' but it still
seems impossible to me.  'SHOULD' should be accompanied by indications
of when it does not apply and I don't really see this.  I think we are
still leaving the barn door wide open.  I would say something like
"These techniques are only defined for ..."
since I think any RFC2119 language unenforceable.

1.4
"Security implications related to
  this change are discussed in Security Considerations (Section 4)."
Not really, section 4 refers you to section 3.

2.1
"The NETCONF/RESTCONF server initiates a TCP connection request
      (SYN) to the NETCONF/RESTCONF client.  "
A strict reading of this allows a NETCONF server to initiate connection
of a RESTCONF client!  I think you need
'NETCONF server or RESTCONF server' twice with a ',respectively' tacked
on

"depending on how it is configured."
Again, this allows you to configure a RESTCONF server to use port X.  It
is not configuration, it is a question of which port you have just
called that determines what the server fires up.

"Using this TCP connection, the NETCONF/RESTCONF server MUST
      immediately start using either the SSH-server [RFC4253] or the
      TLS-server [RFC5246] protocol.
If the connection was made to PORT-X (or a user chosen non-default
port), then the SSH-server protocol is initiated; if the connection was
made to either port PORT-Y or PORT-Z (or a user-chosen non-deault port),
then the TLS-server protocol is initiated."

" Once the SSH or TLS connection is established, the NETCONF/
 RESTCONF server MUST immediately start using either the NETCONF-server
[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] protocol,
depending on how it is configured.  "

Same story, it is the port not the configuration that matters. Perhaps
" Once the SSH or TLS connection is established, the NETCONF/
RESTCONF server MUST immediately start using either the NETCONF-server
[RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf]
protocol, depending on the port to which the connection has been
established."

3
same comments about
"depending on how it is configured"
twice

3.2 I need to go through this many more times but meanwhile

"information  persisted previously."
I don't understand.

"This IP address could be used as an identifier directly, but doing "
so should come with a health warning; source IP addresses are forgeable
in the Internet.

"Yet another option for identifying a NETCONF/RESTCONF server is for
its host key or certificate to encode its identity directly (e.g.,
   within the "Subject" field).  "

What 'Subject field' is that?  I am not familiar with one.

4
"An attacker could DoS the "
I just read an AD review (in IESG review I think ) that said 'Dos is not
a verb'!

Tom Petch

----- Original Message -----
From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 03, 2015 10:16 PM
Subject: [Netconf] WG Last Call for draft-ietf-netconf-call-home-04 and
draft-ietf-netconf-server-model-06 WAS:FW: call-home-04 and
server-model-06 available - All Open issues closed

Dear NETCONF WG,

Please review and send your comments to the NETCONF WG mailing list by
March 17, 2015 EOB PT.

Call Home and Server Model drafts are planned to publish as standard
track documents.

Please state explicitly that you have read/reviewed and whether you
support the publication of the drafts.
Please indicate also if you plan to implement or have already
implementation experience with the these drafts.

Thank you,
Mehmet and Mahesh

From: Netconf [mailto:[email-masked]] On Behalf Of ext Ersue,
Mehmet (NSN - DE/Munich)
Sent: Thursday, February 05, 2015 5:30 PM
To: [email-masked]
Subject: [Netconf] call-home-04 and server-model-06 available - All Open
issues closed

All,

all call-home issues have been solved and there are 3 issues for
server-model draft in REVIEW state.
See
https://github.com/netconf-wg/call-home/issues?q=is%3Aissue+is%3Aclosed
and
https://github.com/netconf-wg/server-model/issues.

Please check the provided solutions in the updated drafts and comment
before we go to WGLC after the end of Restconf LC.

Regards,
Mehmet

------------------------------------------------------------------------
--------

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: t.petch <[email-masked]>
Date: Thu, 5 Mar 2015 16:06:26 +0000

A separate comment to those I made earlier.

What is the right term to refer to Netconf connections that are NOT
using call home?

This I-D sometimes talks of 'standard' (which makes call home
nonstandard), sometimes of 'normal circumstances' (which makes call home
abnormal).

These seem judgmental to me and I would like a less judgmental term.
'Orthodox' (which makes call home heterodox), 'Classic' (which makes
call home modern) or ...  but I think that it needs changing.

But then server-model has 'listen' or 'listening for connections',
fairly consistently,  along with 'call home'

I think that this I-D should be consistent and perhaps consistent with
server-model.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2015 17:17:44 +0100

While I like some of the words, it might be that 'server initiated
connections' and 'client initiated connections' may be easiest to
grasp.

/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: t.petch <[email-masked]>
Date: Fri, 6 Mar 2015 10:04:08 +0000

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "t. petch" <[email-masked]>
Cc: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>;
<[email-masked]>
Sent: Thursday, March 05, 2015 4:17 PM

> connections' and 'client initiated connections' may be easiest to

Yes, I like that.  I am not sure how far you would take it.
'server-model' has many instances of 'call-home' and 'listen' in the
YANG modules for feature, grouping and container where a shorter
identifier seems right.  But it then goes on to use 'call home' and
'listen' extensively in the 'description' clauses, which seems to follow
logically, and also in the textual sections, s.1 and s.2.  It seems
unnatural to draw a line between the terminology of the textual sections
and the YANG modules so 'server-model' then ends up with 'call(-)home'
and 'listen(ing)' everywhere (with some tidying up of the actual
spelling perhaps) .

Logically, then, we end up with 'server initiated connections' and
'client initiated connections'  in the call home I-D with an explanation
somewhere, probably in both I-Ds, that this maps onto 'call-home' and
'listen'.

Mmmmm... I am ok with that even if it is not as tidy as I first
envisioned.

Tom Petch

> > > Subject: [Netconf] call-home-04 and server-model-06 available -
All
> > Open

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Mar 2015 11:18:05 +0100

> Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT.

Here is my review of draft-ietf-netconf-call-home-04.txt.

- Perhaps the second bullet in 2.1 can be improved. Perhaps slight
  rewording helps to make things a bit clearer?

    Change "the SSH-server protocol is used for PORT-X" to "the
    SSH-server protocol is used after connecting to the remote port
    PORT-X" and change "the TLS-server protocol is used for either
    port PORT-Y or PORT-Z" to "the TLS-server protocol is used after
    connecting to one of the remote ports PORT-Y or PORT-Z".
  
- Should the text say something about the assumption that a mismatch
  (a NR server using SSH towards a remote port assuming TLS) leads to
  a failure discovered by the secure transport protocols and to a
  failure of the connection attempt? I guess we do not want systems to
  probe which protocol is available, as this might be a way to try
  downgrade attacks in case one of the protocols has vulnerabities.

- Similarly as above, perhaps change the text in the 3rd bullet in 2.1
  as well:

  OLD
        [...] Assuming the use of
        the IANA-assigned ports, the NETCONF-server protocol is used for
        PORT-X or PORT-Y and the RESTCONF-server protocol is used for
        PORT-Z.

  NEW

        [...] Assuming the use of
	the IANA-assigned ports, the NETCONF-server protocol is used
	over the secure transports to the remote ports PORT-X and
	PORT-Y and the RESTCONF-server protocol is used over the
	secure transport to the remote port PORT-Z.

- Third bullet in section 3.1, similar as suggested above:

  OLD

      For example, assuming the use of the IANA-assigned ports, the SSH-
      client protocol is used for PORT-X and the TLS-client protocol is
      used for either port PORT-Y or PORT-Z.

  NEW

      For example, assuming the use of the IANA-assigned ports, the
      SSH- client protocol is used for connections accepted on PORT-X
      and the TLS-client protocol is used for connections accepted on
      one of the ports PORT-Y or PORT-Z.

- Fourth bullet in section 3.1, similar as suggested above:

- The document refers to [RFC5539] but it should likely refer to
  5539bis. I am not sure the reference of RFC7230 is convincing in the
  last bullet in section 3.1 since this is at the end a generic
  reference to RFC HTTP 1.1.

- If the document uses labels such as S1, S2, S3 and C1, C2, C3 for
  the various server and client protocol operation steps, it becomes a
  bit easier to refer to them ('step C3' is easier to write than
  'third bullet in section 3.1').

- In section 3.2, I think the phrase "this action provides essential
  input" is a bit vague. I think the key here is that the client
  normally has an idea of the expected identity residing at the remote
  server side before even initiating a connection. We probably need to
  make sure we use the proper terminology here (security people should
  tell us).

- 3rd paragraph in section 3.2: For certain NATs, you would get a
  predictable IP address for all N/R servers behind it but then the IP
  address is shared and not unique. This should probably also be
  mentioned as another reason for not using IP addresses (despite the
  fact that they are not strong identifiers from a security
  perspective in any case).

- Is there a reason why verification of the SSH/TLS server's hostkey
  is not required using a MUST? I am actually confused with regard to
  the next paragraph. If the server has a certificate, I may be able
  to verify the certificate and then accept the incoming connection
  because I trust the certificate shown by the server. I do not know
  what his has to do with an identity encoded in the "Subject" field?
  Such a thing would be just a replacement for the fingerprint I would
  otherwise use, no?

- Since the text recommends the usage of certificates, should there be
  explicit text warning about shipping multiple boxes with the same
  certificate? Should there be hints at choosing proper lifetimes and
  the need to handle certificate updates or to handle certificates of
  devices that were 'lost' or 'stolen'? Or at least have hints that
  devices should at least make it difficult to steal certificates?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Mar 2015 23:40:28 +0100

> Please review and send your comments to the NETCONF WG mailing list by March 17, 2015 EOB PT.

Here is my review of draft-ietf-netconf-server-model-06:

* sec 2.4: What is 'TLS _transport-level_ authentication'? Why not
  just use 'TLS authentication' or perhaps even clearer 'TLS client
  authentication'?

* sec 2.6: Do we really need 'northbound application' terminology? Why
  not call it simply a NETCONF/RESTCONF client? There might also be
  possible confusion with phrases such as "Assuming an application has
  more than one server" - the server here seems to be the NETCONF
  client to call home to. Anyway, if we do need new terminology, I
  think we should properly define it to avoid any confusion.

* sec 3: Is it a good idea to name the top-level node netconf-server?
  Is this name consistent with how we name other things?

* sec 3: Can I have a server listening for SSH and accepting call home
  over TLS? Would features work out in such a case or would such a
  server make a client believe that the server is also allowing call
  home via SSH and incoming connections via TLS?
   
* sec 3.1.4: s/when RFC 6187 is supported/when X.509v3 certificates for SSH are supported [RFC6187]/

* sec 3: Are certificates sometimes represented as strings and
  sometimes represented as binary?

* sec 4: Is it a good idea to name the top-level node restconf-server?
  Is this name consistent with how we name other things? (see also above)

* sec 3.2: also mention that the module imports an extension from [RFC6536].

* sec 3.2:

  - is import by revision needed?

  - s/supports RFC 6187/supports X.509v3 certificates for SSH authentication/

  - Are groupings useful that are only used once? Are they really
    improving readability?

  - s/issuing RPC requests/carrying any NETCONF messages/

  - is there any motivation for the upper bounds of hello-timeout and
    idle-timeout?

  - better description for 'listen'?

  - is there a motivation for the upper bound of max-sessions?

  - why is max-sessions part of the listen subtree? do call home
    sessions count in here as well? it seems that max-session may be
    another global session parameter

  - neither address nor port are mandatory for a listening endpoint;
    since the port has a default, should address be mandatory?

  - is it useful to reference the RFC itself in a reference clause of
    a specific leaf (e.g., 'keep-alives' given that there is a
    'global' reference to the RFC? Probably it is useful since it
    references a specific section but then the section references
    does not make much sense...

  - better description for 'call-home'?

  - The description of 'application' talks about NETCONF clients, so
    application == NETCONF clients?

  - is there a motivation for the 15 seconds default for the call home
    keep alive timer?

  - is there a motivation for 30 seconds default linger time and 5
    minutes default reconnect time?

  - What is the meaning of "NETCONF servers SHOULD support this flag
    across reboots."? Perhaps it is clearer if the text said "NETCONF
    servers SHOULD be able to remember the last endpoint connected to
    across reboots".

  - how do interval-secs and count-max work for reconnect-strategy if
    an endpoint resolves to multiple IP addresses? Does the
    interval-secs apply every address of an endpoint or to all
    addresses of an endpoint? Does count-max increment for each
    address of an endpoint or just once for a given endpoint?

  - would it make sense to introduce a typedef for the X509
    certificates?

  - for certs, we copy binary certs into the config but for ssh host
    keys, we reference them using some strings that act as unique
    identifiers into an undefined pool of host keys. This is somewhat
    asymmetric and how do I configure a host-key without knowing which
    host keys the box has available? The problem likely is that we
    lack a generic infrastructure for managing SSH and TLS
    credentials. But would the approach to model pools of keys not be
    the more practical solution?

* sec 4.2: also	mention that the module imports an extension from [RFC6536].

* sec 4.2:

  - is import by revision needed?

  - would it not make sense to factor out some common groupings so
    that things can be reused instead of being defined multiple times?

  - what is "RFC ZZZZ: Client Authentication over New TLS Connection"?
    the editor instructions refer to draft-thomson-httpbis-cant but
    this one does not exist anymore?

  - several of the comments for the netconf server module also apply
    to the restconf server module - I am not repeating them here,
    assuming that any changes will be applied consistently anyway

* sec 5: remove the first sentence?

* sec 5.2: is this document the right place to require (MUST) that
  call home servers advertise "peer_allowed_to_send" per [RFC6520]?
  If this is a general requirement, should it not be in the call home
  document?

* sec 6: the 2nd paragraph should also refer to ietf-restconf-server

* sec 6: there may be more that is worth saying, e.g., that
  misconfigured call home server could be used to DDOS some other
  victim by repeatedly connecting and starting a TLS conversation.

* sec A: please use IP addresses reserved for documentation in the
  examples.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Mar 2015 01:26:34 +0000

>  just use 'TLS authentication' or perhaps even clearer 'TLS client

Good catch.  Will use "TLS client authentication"

>  think we should properly define it to avoid any confusion.

The term "application" is coming from the YANG model, where we have:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw call-home {call-home}?
            +--rw application* [name]
               ...

My intent was to pick a term that would make sense in GUI and CLI.  But
maybe this is better:

   module: ietf-netconf-server
      +--rw netconf-server
         +--rw call-home {call-home}?
            +--rw netconf-client* [name]
               ...

What do you think?   The term used throughout the draft will fallout from
this.  If we decide to use "application", I will add a proper Terminology
section, per Martin's comment.

>  Is this name consistent with how we name other things?

What else would you have?  FWIW, RFC 6022 has "netconf-state".

In case it helps, example A.1 shows:

  <netconf-server xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-server">
    <session-options>...</session-options>
    <listen>...</listen>

    <call-home>...</call-home>
    <ssh>...</ssh>
  </netconf-server>

>  home via SSH and incoming connections via TLS?

You can certainly configure that, but the model doesn't support the
NETCONF server being able to only support those specific variations.
This is why I was trying to use the YANG 1.1 style if-feature statements
in -04.  We could use long feature names to cover these specific
variations, but I didn't think it worth the bother.  Do you?

>  sometimes represented as binary?

That's an oversight, they should all be binary.

>  Is this name consistent with how we name other things? (see also above)

Let's apply the resolution to the above comment here as well.

>  - is import by revision needed?

At the time I submitted this draft, it was my understanding that import by
revision was best practice, and that prior YANG modules were in violation.
 Recent YANG 1.1 conformance discussions seem to be swinging the other
direction now, but with potential to swing back again.  I don't know what
to *right* thing to do is.   Perhaps taking it out is the way to go
because, even if it's wrong, it will at least be in the company of other
published modules  ;)

>  - Are groupings useful that are only used once? Are they really

Guess not.  I tried twice, but it doesn't seem popular.  I will remove all
groupings that are used only once.

>  - is there any motivation for the upper bounds of hello-timeout and

This came from a YANG snippet Andy provided.  I'm sure that it's along the
lines of "if more than an hour, it might as well use infinity".
Personally, I don't see a reason to limit it, but I do think that only
having "seconds" units can become unwieldy and thus might suggest a
2-tuple whereby one value is a numeric and the other an enum like
{seconds, minutes, hours, days}.  What do you think?

>  - is there a motivation for the upper bound of max-sessions?

This YANG snippet also came from Andy, but I don't see a reason to limit
it here.   Andy?

>    another global session parameter

Yes, this makes sense to me as well, though what happens if we get into
the pathological case of the number of call-home sessions configured is
greater than the configured max-sessions count?  Is there a way to write
a validation expression to test for this?

>    since the port has a default, should address be mandatory?

Sounds reasonable.  An alternative might be to have a default to represent
"all configured interfaces" - what do you think?

>    does not make much sense...

Maybe only mildly useful, but definitely inconsistent to other YANG
modules.  Take it out?

>    application == NETCONF clients?

Yes.  This is related to comment above as well.

>    minutes default reconnect time?

For all of these, I just figured they were sensible choices.  Do they
seem OK to you?

>    servers SHOULD be able to remember the last endpoint connected to

Martin had a similar comment - will clarify in the text

>    address of an endpoint or just once for a given endpoint?

Interesting point, that a hostname may expand into a list of IPs.  What
makes sense to me is that the list of IPs would be treated as if they were
specified explicitly.  For example, let's say a configured application
(netconf client?) has 3 endpoints (EP1, EP2, and EP3), but they're all
hostnames that expand into two IP addresses, then the netconf server
behavior would be as if it had them configured explicitly: EP1.1, EP1.2,
EP2.1, EP2.2, EP3.1, EP3.2.  That is, with would try EP1.1 count-max times
before trying EP1.2 count-max times, and so on. Does this also make sense
to you?  If so, then I think that it's just a matter of writing it up so
the text spells it out.

>  - would it make sense to introduce a typedef for the X509

Maybe, but I wonder if you're saying this after seeing this:

      leaf-list certificate {
        type string;
        min-elements 1;
        description
          "An unordered list of certificates the TLS server can pick
           from when sending its Server Certificate message.  The value
           of the string is the unique identifier for a certificate
           configured on the system.  How valid values are discovered
           is outside the scope of this module, but they are envisioned
           to be the keys for a list of certificates provided
           by another YANG module";
        reference
          "RFC 5246: The TLS Protocol, Section 7.4.2";
      }

Or this?

      leaf-list trusted-ca-cert {
        type binary;
        ordered-by system;
        nacm:default-deny-write;
        description
          "The binary certificate structure as specified by RFC
           5246, Section 7.4.6, i.e.,: opaque ASN.1Cert<1..2^24>;
          ";

The former was by yours truly later was lifted from another draft.  My
plan from Martin's review was to make the former look like the later, but
you think a typedef would be better?

>    the more practical solution?

The binary certs we're copying into the configuration are being used for
client-cert authentication.  Here I'm referring to
/netconf-server/[ssh|tls]/x509/trusted-ca-certs and
/netconf-server/[ssh|tls]/x509/trusted-client-certs.  There is no SSH
equivalent for authenticating clients when the clients use password or key
based authentication, because ietf-system.yang module from 7317 does it
already.  So, yes, there is an asymmetry here, but what can we do?

Separately, there is configuration for what host-keys the SSH-server
presents and what server-certificates the TLS-server presents.  Here I'm
referring to 
/netconf-server/listen/endpoint/[ssh/host-keys|tls/certificates] and
/netconf-server/call-home/application/[ssh/host-keys|tls/certificates].
Currently these are as you say, a named reference to a value presumed to
be configured elsewhere.  The good news is that how this is done is
symmetric for both SSH and TLS.  As for modeling pools of keys, I think
that this is what sever-model-04 had - read-only lists of SSH host-keys
and certificates just so they could be referenced here.  This was
discussed at IETF 91 meeting with the resolution to remove them from this
draft.  This issue was tracked here as well:
https://github.com/netconf-wg/server-model/issues/20.

>    that things can be reused instead of being defined multiple times?

Do you mean between the ietf-netconf-server and ietf-restconf-server
modules?

>    this one does not exist anymore?

It is here, but expired:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01

I've been discussing with Martin Thomson about it.  I'll probably work
with him in the httpbis WG to resurrect it and get it done.

>    assuming that any changes will be applied consistently anyway

Yes, understood, symmetric changes would be made to both

>  If this is a general requirement, should it not be in the call home

Er, yes, I think that you're right

>* sec A: please use IP addresses reserved for documentation in the

I didn't know there was such a thing - can you provide a pointer to the
RFC for this?

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 20 Mar 2015 10:06:31 +0100 (CET)

> Maybe only mildly useful, but definitely inconsistent to other YANG

I think you should keep it for this leaf.  The reason is that
otherwise it becomes unclear what keep alive means.  (this was the
reason we added the reference in the first place ;)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Mar 2015 12:12:29 +0100

> reason we added the reference in the first place ;)

Well, if it is unclear, why not add text to the description to make it
clearer?

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Mar 2015 18:31:22 +0000

Hi Tom,

Thank you for this review, and the other focusing on section 3.2 of
call-home draft.  For the most part, you're asking for improvements in the
flow and wording in the draft, for which I'll incorporate when editing the
draft next.

Below are some additional responses.

Thanks,
Kent

:sigh:

>certificates, public keys - is right

Oh good, the restructuring of the documents we took on is paying off

>but that does not mean it is always

This came up before.  In fact, I raised the issue originally and did try
to make it better.  Apparently not.  I have reopened
https://github.com/netconf-wg/call-home/issues/6 to track this.

>needs saying up front IMO.

The scope is: NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS

But it so happens that NETCONF/SSH can also support X.509 certificates,
which is really important for the zero-touch solution.  To be honest, I'm
beginning to think that we should take out most of section 3.2 (the one
that leads to recommending X.509 host-keys).  For the call-home protocol,
all we need to say is that the client needs to:

 1) extract the server's identity
	- options: source-ip, host-key lookup, or PKI
 2) validate the server's host-key
	- options: pinning or PKI.

I think the current text is overstepping its scope and, in the process,
hiding the essential bits.  You providing an extensive response on section
3.2 separately, but I'm thinking another solution might be to make most of
this section 3.2 disappear

>RESTCONFconnection is over TLS, the NETCONF over TLS or SSH. "

True, SSH was removed from the abstract when we added RESTCONF, as I
didn't want to introductory paragraphs to already be in the weeds.  I like
your suggested text.

>B', but no 'C and D' to be respective to.]

Not that it matters, but isn't it:

  A = NETCONF Call Home
  B = RESTCONF Call Home
  C = enable a NETCONF server to initiate a
      secure connection to a NETCONF client
  D = enable a RESTCONF server to initiate a
      secure connection to a RESTCONF client

So, A goes with C and B goes with D?

>(as well as fleshing this out later).

I think the word "transport" simply refers to the layer below.  So TCP is
the transport for SSH and TLS, whereas SSH is a transport for NETCONF and
TLS is a transport for NETCONF and the transport for HTTPS/RESTCONF.
This also seems consistent with the term's usage in RFCs 5539 and 6242.

Nonetheless, as Rohit's recent confusion illustrates, it seems that this
draft still does not spell out clearly enough this point.  So, how about
this:

=====START=====

   Both NETCONF Call Home and RESTCONF Call Home preserve all client/
   server roles, except for at the TCP transport layer, as when compared
   to standard NETCONF and RESTCONF connections.  Specifically,
   regardless if call home is used or not, the SSH, TLS, NETCONF, and
   RESTCONF roles are the same, only the TCP roles vary.  Stated another
   way, and depicted below, the network element is always the NETCONF/
   RESTCONF server, as well as also always the SSH/TLS server.  Indeed,
   the only difference is in which peer initiates the underlying TCP
   connection.

            +--------------------+------------+-------------+
            |    Protocol Layer  |  Standard  |  Call home  |
            +--------------------+------------+-------------+
            |  NETCONF/RESTCONF  |   server   |   server    |
            |           SSH/TLS  |   server   |   server    |
            |               TCP  |   server   |   client    |
            +--------------------+------------+-------------+

               Client/Server Roles for the Network Element

  Please note that throughout this document, including the text above,
  are switches such as "NETCONF/RESTCONF" and "SSH/TLS".  It should
  be understood that the only valid combinations are NETCONF/SSH [RFC
  6242], NETCONF/TLS [RFC 5593], and RESTCONF/TLS
[draft-ietf-netconf-restconf].
  In particular, never is it intended that RESTCONF/SSH is a valid
  combination.

=====STOP=====

>since I think any RFC2119 language unenforceable.

Sound OK to me, do others agree?

>Not really, section 4 refers you to section 3.

Good point.  There use to be more text there at one time though ;)

>On

OK

>called that determines what the server fires up.

[assuming section 2.1, there would be a different response if for section
3.1]

No, non-standard and even mismatched IANA-assigned ports are possible.
>From the network-elements POV, what matters is how it was configured.  For
example, in the server-model draft, the configuration allows the
transport-specific default-port destination port to be overwritten.

>then the TLS-server protocol is initiated."

I'm confused, are you providing alternate text here?

>protocol, depending on the port to which the connection has been

See above for my comment on section 2.1

>Twice

Actually, here I think it is different, in that I believe we can use a
MUST (or a SHOULD, since it's not enforceable?) to assert that the right
protocol is started on the IANA-assigned port.  That is, ports must/should
only be used for the protocols as assigned by IANA.  For non-standard
ports, it would be as configured.  Tom, I might need your wordsmithing
prowess here ;)

>What 'Subject field' is that?  I am not familiar with one.

You did provide a separate response focusing on section 3.2, so I'll defer
comment on it here now.

>I just read an AD review (in IESG review I think ) that said 'Dos is not

Good point, it should be "An attacker could launch a denial of service
(DoS) attack on the..."

Thanks again,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Mar 2015 19:34:33 +0000

Hi Juergen,

>Here is my review of draft-ietf-netconf-call-home-04.txt.

Thank you for this review!

>    connecting to one of the remote ports PORT-Y or PORT-Z".

Tom also had comments here.  Yes, your sentences are more clear.

>  downgrade attacks in case one of the protocols has vulnerabities.

I'm not following you.  Port mapping is certainly a common attack vector
and there is not much that can be done to prevent it. In the case of
mismatched protocols (SSH client --> TLS server, or visa versa), my
expectation is that the both sides will get a protocol error of some sort.
 Do we need to say anything in the text though?

OK

>      one of the ports PORT-Y or PORT-Z.

I'm see ing a pattern here ;)

>- Fourth bullet in section 3.1, similar as suggested above:

Understood

>  5539bis.

I actually meant 5539, since 5539bis isn't needed from a normative
perspective.  But I might as well now, since there is a normative
reference to the RESTCONF draft,

>I am not sure the reference of RFC7230 is convincing in the

Yes, in the end, it's just HTTPS, but don't you think something should be
said?  Unfortunately there isn't a more formal HTTP/TLS binding spec we
can reference...

>  'third bullet in section 3.1').

Hmmm, at risk of changing the document structure, what do you think about
there being an image like:

        NETCONF/RESTCONF                     NETCONF/RESTCONF
            Server                               Client
              |                                    |

              |         1. TCP                     |

              |----------------------------------->|

              |                                    |

              |                                    |

              |         2. SSH/TLS                 |

              |<-----------------------------------|
              |                                    |

              |                                    |

              |         3. NETCONF/RESTCONF        |

              |<-----------------------------------|
              |                                    |

And then have the text speak to 1-3, something like:

	1 TCP Connection
	1.1 NETCONF/RESTCONF-server's perspective
	1.2 NETCONF/RESTCONF-client's perspective

	2 SSH/TLS Connection
	2.1 NETCONF/RESTCONF-server's perspective
	2.2 NETCONF/RESTCONF-client's perspective

	3 NETCONF/RESTCONF Connection
	3.1 NETCONF/RESTCONF-server's perspective
	3.2 NETCONF/RESTCONF-client's perspective

What do you think?

>  make sure we use the proper terminology here (security people should

I'll look into it

OK

>  Such a thing would be just a replacement for the fingerprint I would

What you describe is "pinning"
(https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning
).

Recall that under normal circumstances, the client provides an initial
hostname (e.g., https://example.com) and that the Subject field inside the
certificate is expected a match (e.g., DNS:example.com).  So, there are
two steps: 1) have I accepted this cert before and 2) does the identity in
the Subject match the client-provided reference identifier.

Does this help?  If not, can you identify which paragraph your referencing
here?

>  devices should at least make it difficult to steal certificates?

Boxes already should never share certs, as that would mean they share
private keys, which violates a best practice.  Should I look for a
reference on that? 

Private keys should be protected, ideally by a trust protection module
(TPM).   When protected by a TPM, their expirations are typically set to a
very large value (IEEE 802.1AR-2009 spec actually says to use
"99991231235959Z"), otherwise, it's recommended to periodically refresh
the private key (once a year is what I shoot for on my servers).

I don't know if any of this belongs in the Security Considerations
section, at least not in this draft.  It seems more guidance that would be
provided by other drafts.

Thanks again,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Mar 2015 21:30:06 +0100

>  Do we need to say anything in the text though?

I do not know either but perhaps it makes sense to be explicit that
implementations MUST use the security protocol configured for a
certain port.

> reference to the RESTCONF draft,

I do not see how this relates to RESTCONF since RFC 5539bis is about
NETCONF. Anyway, since 5539bis is on the IESG agenda now and it will
retire RFC 5539 once approved, I think you will just trigger requests
later about a stale reference.

> said?  Unfortunately there isn't a more formal HTTP/TLS binding spec we

So you are saying that RESTCONF does not have to say anything about
its usage of TLS? Perhaps that is true but even then, would RFC2818
not be the more appropriate RFC to refer to? My understanding is that
RFC7230 only updates RFC2818 by revising the https URI scheme
definition.
 
>         NETCONF/RESTCONF                     NETCONF/RESTCONF

No, this is not what I was asking for (nor does it bring any
additional clarity if you ask me). What I suggested to replace the
bullets in 2.1 and 3.1 with numbered items that I can refer to:

2.1 Protocol Operation

  S1 ...
  
  S2 ...
  
  S3 ...
  
  S4 ...
  
  S5 ...

3.1 Protocol Operation

  C1 ...

  C2 ...

  C3 ...
  
  C4 ...
  
  C5 ...

Its a purely editorial change that allows me to simply refer to 'step
C3'.

> Does this help?  If not, can you identify which paragraph your referencing

I think the current text does not require to verify the certificate. I
think there should be a MUST verify somewhere at the last paragraph on
page 7. This is in particular important because the client does not
have an expectation which server is calling in, so everything relies
on a decision whether the presented certificate is valid and is one of
the certificates that the client finds acceptable according to its
local policy.

> provided by other drafts.

If there are other drafts the security considerations can refer to,
great. If there is nothing suitable, well, then I think we need to
produce some meaningful text. The key here is to help developers
making mistakes that could be disastrous for protocols that have the
power to change configurations.

/js

---

From: Kent Watsen <[email-masked]>
Date: Fri, 20 Mar 2015 21:53:27 +0000

>implementations MUST use the security protocol configured for a

As I replied to Tom P., I think we can say that the client and server MUST
(perhaps SHOULD, since it's not enforceable) run the appropriate protocol
when one of the IANA-assigned port is used.  Beyond that, it seems that
scope of this draft (NETCONF/SSH, NETCONF/TLS, RESTCONF/TLS) is tripping
us up.  The draft for a single protocol wouldn't have such a problem...

>later about a stale reference.

I only meant to mention the RESTCONF draft since it is also not yet an RFC
- previously the call-home draft only had normative references on RFCs (no
drafts).  Doesn't matter, as you say, I'll ref 5539bis now.

>RFC7230 only updates RFC2818 by revising the https URI scheme

Yeah, I guess restconf-04 has more in it now (it didn't before) that might
be worth referencing.

>> there being an image like:
<snip/>
>bullets in 2.1 and 3.1 with numbered items that I can refer to:
<snip/>
>Its a purely editorial change that allows me to simply refer to 'step

I knew what you meant, I was just offering an option.  It's OK, I prefer
the easier route if you don't think my suggestion helps any.

>the certificates that the client finds acceptable according to its

This is clear, but I'm still not sure which paragraph in section 3.2
you're referencing here.

>power to change configurations.

OK, I'll see what I can find.

K.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Mar 2015 23:32:29 +0100

> us up.  The draft for a single protocol wouldn't have such a problem...

It is enforcable whether you run SSH or TLS. This should be a
MUST. And this has nothing to do with NETCONF / RESTCONF. My concern
is that I do connect to a PORT where I expect SSH but then the server
is willing to run TLS over it in case I do not send an SSH hello
message. I am concerned about having a way to change the security
protocol.
 
> This is clear, but I'm still not sure which paragraph in section 3.2

The paragraph starting with this:

  The next information a NETCONF/RESTCONF client learns is provided by

It could also be that I am simply a bit confused since you talk about
using information embedded in a certificate later. Perhaps this sentence

   [...] This strategy also provides a mechanism to
   verify the identity of the NETCONF/RESTCONF server, in that a secure
   connection can only be established with the NETCONF/RESTCONF server
   having the matching private key.

is addressing my concern but I was kind of looking more for text that
is more explicit what an implementation MUST do. Somehow, section 3.2
reads more like an essay about various server identification options
instead of giving clear guidance what implementors should do (or
should not do).

/js

---

From: t.petch <[email-masked]>
Date: Sun, 22 Mar 2015 09:53:58 +0000

This is getting tangled; see my comments at the end.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Kent Watsen" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 20, 2015 10:32 PM

> > >> expectation is that the both sides will get a protocol error of
some
> > >>sort.

Juergen

Yes, I agree, more like an essay than a Standard.

I proposed the replacement text below but feel I did not go far enough,
still somewhat essay like.  Kent's response comes after and gave a
succinct summary but I think we need something between the two.

 ====================================================
 3.2.  Server Identification and Authentication

    When a NETCONF/RESTCONF client initiates the
    connection to the NETCONF/RESTCONF server, the client has prior
 knowledge of the identity of the NETCONF/RESTCONF server it is
 connecting to.  When using TLS or SSH with certificates,
    the NETCONF client can then check the identity of the server
 according to
    Section 6 of [RFC6125].
    Similar considerations apply when using SSH with host keys.

 When the connection is initiated by the NETCONF/RESTCONF server, the
 NETCONF/RESTCONF client does not have any prior knowledge of the
 identity of the NETCONF/RESTCONF server which has initiated the
 connection.  The NETCONF/RESTCONF
  client must derive the identity of the NETCONF/RESTCONF server from
  information provided by the network or by the NETCONF/RESTCONF server
    itself.  This section describes strategies a NETCONF/RESTCONF client
    can then use to identify a NETCONF/RESTCONF server.

 A NETCONF/RESTCONF client must also authenticate the identity of the
 server.  This is always an issue but especially so when the
 NETCONF/RESTCONF server initiates the connection since this approach is
 common for newly deployed NETCONF/RESTCONF servers.

 The first piece of information that a NETCONF/RESTCONF client learns
 when the server initiates the connection is the IP address of the
 NETCONF/RESTCONF server, i.e the source address of the TCP connection.
 This IP address is an identifier but is only reliable in networks that
 use known static addresses.  This case is infrequent; so it is NOT
 RECOMMENDED to identify a NETCONF/RESTCONF server by its source IP
 address.

 The next piece of information a NETCONF/RESTCONF client learns is
 provided by the NETCONF/RESTCONF server in the form of a host-key (for
 SSH) or a certificate (for SSH or TLS).  This host-key or certificate,
 either in its
 entirety or as a fingerprint, can be used to look up an identifier for
 the NETCONF/RESTCONF server.  Each NETCONF/RESTCONF
 server is assumed to have a statistically unique public key, even in
 virtualized environments.  This approach also provides authentication
in
 that a secure connection can only be established when the
 NETCONF/RESTCONF server can demonstrate possession of
 the matching private key.  This approach is common with SSH clients but
 could be used equally well by TLS clients.  It may be the required when
 the NETCONF/RESTCONF servers have self-signed certificates.

 [** I do not understand the next OLD paragraph and so am guessing here.
 Doubtless I will be told where my guesses are wrong]

 A variation on the previous option can be used when the manufacturer of
 the NETCONF/RESTCONF servers is a trusted CA and provisions the
 NETCONF/RESTCONF servers with certificates such as is described by
 [Std-802.1AR-2009].  After verifying that the certificate is valid
 [RFC5280], an identifier can be extracted from the certificate, e.g.
 from the subjectAltName.  The NETCONF/RESTCONF client SHOULD still be
 configured with the CA certificate and a list of expected identifiers
of
 the NETCONF/RESTCONF servers, as supplied by the manufacturer.

 [Which seems very close to the usual RFC6125 case - what am I missing?]

    Note that while TLS uses X.509 certificates by default, using X.509
    certificates with SSH requires both the NETCONF client and server to
    support [RFC6187].
 ==================================================
 I would probably cut down on the number of times NETCONF/RESTCONF
 appears but am not too bothered by it.
===================================================

Kent's response

"For the call-home protocol,
all we need to say is that the client needs to:

I think the current text is overstepping its scope and, in the process,
hiding the essential bits.  You providing an extensive response on
section
3.2 separately, but I'm thinking another solution might be to make most
of
this section 3.2 disappear"

<tp>
Yes, something along those lines.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Sun, 22 Mar 2015 10:14:48 +0000

<inline tp>
Tom Petch

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "t.petch" <[email-masked]>; "Ersue, Mehmet (Nokia - DE/Munich)"
<[email-masked]>; <[email-masked]>
Sent: Friday, March 20, 2015 6:31 PM

Hi Tom,

Thank you for this review, and the other focusing on section 3.2 of
call-home draft.  For the most part, you're asking for improvements in
the
flow and wording in the draft, for which I'll incorporate when editing
the
draft next.

Thanks,
Kent

<snip>

<tp>
Yes, once we have settled 3.2, then I would take another look at this to
see if there any loose ends.

<tp>
Well partially, but I find the I-D unclear on the related credentials,
which I take to be TLS-with-certificates, SSH-with-host-key,
SSH-with-certificates. I am fine with that being the scope but think
that the wording of the I-D does not always bear that out clearly enough
and this was a big issue for 5539bis.
</tp>

But it so happens that NETCONF/SSH can also support X.509 certificates,
which is really important for the zero-touch solution.  To be honest,
I'm
beginning to think that we should take out most of section 3.2 (the one
that leads to recommending X.509 host-keys).  For the call-home
protocol,
all we need to say is that the client needs to:

<tp>
Yes, subject to some agreement on terminology.  As Juergen said, more
like an essay, and my text in my separate response is still too essay
like.

True, SSH was removed from the abstract when we added RESTCONF, as I
didn't want to introductory paragraphs to already be in the weeds.  I
like
your suggested text.

<tp> Good, use it!

<snip discourse on grammar>

>(as well as fleshing this out later).

I think the word "transport" simply refers to the layer below.  So TCP
is
the transport for SSH and TLS, whereas SSH is a transport for NETCONF
and
TLS is a transport for NETCONF and the transport for HTTPS/RESTCONF.
This also seems consistent with the term's usage in RFCs 5539 and 6242.

=====START=====

<tp>
text fine, diagram less so as it, again, could be read as endorsing
RESTCONF over SSH.  I really do want the I-D to be clear that it
excludes that possibility (I have been reading PPVPN lately and boy, it
is confusing because of this sort of mix and match).

=====STOP=====

<tp Hope so

OK

>called that determines what the server fires up.

[assuming section 2.1, there would be a different response if for
section
3.1]

<tp>
Yes but Juergen has picked up on this point too, that if you call home
on a port configured for SSH, then you should only process SSH packets
and discard TLS ones; that we should be crystal clear on; whether the
port is IANA-assigned or not is immaterial, it just causes the sentence
to introduce an unwanted complication.

<tp>
Yes, it is the same point, and the same as Juergen has picked up on.

protocol is started on the IANA-assigned port.  That is, ports
must/should

<tp>
SHOULD, I think (flattery will get you everywhere).  If the port is
IANA-assigned, it should only be used for that which it was assigned.
If the port is user chosen, it should only be used for the protocol, SSH
or TLS, for which it is configured.

I assume that user-defined ports follow the IANA model, that a port is
either for NETCONF-SSH or NETCONF-TLS or RESTCONF-TLS and not a
combination thereof; at least, that is what the I-D says they SHOULD
do - if an implementer wants to go further, then we do not give them any
help or encoiuragement.

>What 'Subject field' is that?  I am not familiar with one.

You did provide a separate response focusing on section 3.2, so I'll
defer
comment on it here now.

<tp
Yes and Juergen's comments are relevant.

Phew!

Tom Petch

Thanks again,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 22 Mar 2015 15:04:18 +0100

> section, per Martin's comment.

I think 'application' is very broad. On the technical side, I think
the issue is how we interpret terms for 'applications' that may have
multiple 'entry points'. Is every 'entry point' a netconf client or is
the 'application' a network client with multiple potentially very
distinct endpoints. It may be necessary to make a distinction here to
avoid any confusion, I am not sure what would be the proper terms to
use. But whatever we do, this needs to be clearly defined. 

>     <call-home>...</call-home>

We may have to look into how we do our naming. I think other YANG
models do not use -server.

> variations, but I didn't think it worth the bother.  Do you?

Hard to tell - but once you need it and it is not there, you are
somewhat screwed.
 
> because, even if it's wrong, it will at least be in the company of other

There was a VRFY call on the YANG 1.1 issue that did not cause any
reaction saying that import by revision actually leads to a workable
solution. So from this point of view, I would rather remove import by
revision.
 
> "all configured interfaces" - what do you think?

This might make sense but then this should be stated explicitly.
 
> to you?  If so, then I think that it's just a matter of writing it up so

As long as it is clearly specified how things should behave I am fine.

> you think a typedef would be better?

I just say this "as specified by RFC 5246, Section 7.4.6 [...]" in
multiple places and hence I thought a typedef could nicely encapsulate
that.

> Do you mean between the ietf-netconf-server and ietf-restconf-server

Yes, and probably others. Having the same thing defined multiple times
is an indication that perhaps a single definition could do as well.

> I didn't know there was such a thing - can you provide a pointer to the

The latest version seems to be https://tools.ietf.org/html/rfc6890

/js