Subject: [Netconf] Few points about draft-ietf-netconf-call-home-04

From: Rohit R Ranade <[email-masked]>
Date: Mon, 9 Mar 2015 05:50:25 +0000

Hi All,

I have a scenario where in my network element comes up and My management element needs to know when it comes up.
The current draft seems to solve it, but a few pain points.

1) In the normal Client-Server model, Client connects and Server accepts connections. But in this case, the Client has to connect and also accept connections. The Server has to connect and also accept connections. The NETCONF Server will have to depend on SSHS and SSHC . The NETCONF Client will have to depend on both SSHS and SSHC. This I feel is not right. 

2) Consider a case where in my management element has multiple IPs, how will the Network element know which IP to connect to ? How will it know the management element's IP ?

3) Currently is there any other Protocol where in this feature of intermixing of Client and Server features has been done ? Are the pain points of those implementations 
Applicable to NETCONF also ? Can those pain points be resolved as part of this draft?

With Regards,
Rohit

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 07 March, 2015 00:10
To: [email-masked]
Subject: Netconf Digest, Vol 85, Issue 9

Send Netconf mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/netconf
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Netconf digest..."

Today's Topics:

   1. Re: 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 (t.petch)
   2. Fw: 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 (t.petch)
   3. Re: zerotouch issues and fixes (Kent Watsen)
   4. Re: Fw: 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 (Kent Watsen)

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

Message: 1
Date: Fri, 6 Mar 2015 10:04:08 +0000
From: t.petch <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [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
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

----- 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

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

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

> /js
>
> On Thu, Mar 05, 2015 at 04:06:26PM +0000, t. petch wrote:
> > 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
> >
> > > ----- Original Message -----
> > > From: "Ersue, Mehmet (Nokia - DE/Munich)" <[email-masked]>
> > > To: <[email-masked]>
> > > Sent: Tuesday, March 03, 2015 10:16 PM
> > >
> > > 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
> > >
> > >
> > >
> > >
> >
> ----------------------------------------------------------------------
> > --
> > > --------
> > >
> > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/netconf
> >
> > _______________________________________________
> > Netconf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/netconf
>
> --
> 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/>

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

Message: 2
Date: Fri, 6 Mar 2015 16:59:58 +0000
From: t.petch <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: [Netconf] Fw: 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
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

 I have read, and re-read and re-read ... section 3.2 of call-home and I
 am struggling.  I am reminded of rfc5539bis where we started out with
 something similar and ended up with
 "  The NETCONF client MUST check the identity of the server according
to
    Section 6 of [RFC6125]."
 which I think was a great idea.

 We cannot go quite that far with the call-home I-D but think we should
 be
 heading in that direction.

 Surely all we need to say, in essence, is that because the server has
 initiated the connection then we have no reference identity and so
 RFC6125 cannot apply.  Therefore the client must be preconfigured with
 whatever it will trust from the server, be that a certificate or a host
 key.  And it should be the certificate of the server; a CA certificate
 on
 its own is not enough since, as we have said already, we have no
 reference identity so knowing that the end user certificate chains back
 to a valid CA is not enough (in general).

 And yes, preconfiguring information is a pain but if you want security,
 you have to do it.

 So along those lines I offer a new 3.2

 ====================================================
 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.

 Which is all the comments I currently have on
 draft-ietf-netconf-call-home-04.

 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,
>
> 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
>
> --=====2634486923681469604=-
>

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

Message: 3
Date: Fri, 6 Mar 2015 18:31:01 +0000
From: Kent Watsen <[email-masked]>
To: Joe Clarke <[email-masked]>, "[email-masked]"
	<[email-masked]>
Subject: Re: [Netconf] zerotouch issues and fixes
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

OK, it seems that there is some support for this approach.  I'd plan to
post an updated draft that captures the idea more completely.  We can
always roll it back if needed...

Thanks,
Kent

On 3/3/15, 11:15 AM, "Joe Clarke" <[email-masked]> wrote:

>On 3/2/15 10:43 AM, Kent Watsen wrote:
>>
>>
>>> I think this approach is reasonable.  The interaction with the vendor
>>>is
>>> minimal (only to claim the device-IDs and get the voucher).
>>
>> Exactly, this solution optimizes for the vendor - it's very low-touch
>>and
>> doesn't rely on a realtime lookup service.  But "reasonable" sounds
>> uncommitted - what we need to know is it's better - what do you think?
>
>Sorry, didn't mean to sound noncommittal.  I like it.  I just think the
>questions I had raised need to be addressed (i.e., around Owner ID and
>verifying expiry on the device's part).
>
>>
>>
>>> Though, the
>>> time-to-live of the voucher needs to be accounted for by the device.
>>>It
>>> needs to confirm the voucher is still "alive."
>>
>> Yes, there is a presumption that the device has an accurate clock.  Such
>> it is with PKI in general.  For instance, CRLs are only useful if
>>they're
>> relatively fresh (a year-old CRL is not very useful).
>
>Of course.  It's just you didn't mention that in your rough
>walk-through.  That needs to be part of the process.
>
>>
>>
>>
>>> Would it make sense to
>>> have a per-device TTL in the voucher?
>>
>> This would be doable.  As a voucher is a data file (not a X.509
>> certificate), for which we could define schema for, and thus it could
>>take
>> any form we deem best.  That said, I question if it makes sense for a
>> vendor to issue a voucher with varying TTLs.  Is the vendor suppose to
>> know that some device's ownership is more volatile than others?  - or do
>> you see this as user-input?
>
>I see this as user input.  The use case I envision is that the owner
>might set a certain timeline for other devices to give a safety net to
>prevent old devices from bootstrapping.  It may not be common, and thus
>this could be a MAY.  It just offers flexibility.
>
>>
>>
>>> I also think there needs to be a way for the NMS to request an owner
>>>ID.
>>>   The reason for this is what happens if I have to replace the NMS.  I
>>> would need a new private key and a new CSR.  While I could get a new
>>> voucher with the new owner ID, this would likely be more of a hassle as
>>> the vendor will likely associate the devices with one owner ID.
>>
>> Yes, vendors would have to be able to reissue the NMS certificates.
>> Vendors could re-assign the same Owner ID the NMS had before or
>>generate a
>> new one.  If a new Owner ID is generated, then the vendor would also
>>need
>> to reissue Vouchers for devices that have not yet been claimed (e.g.,
>>gone
>> through the zerotouch process).
>
>How do we state this in the draft?  I think it deserves a callout.  The
>Owner ID can't simply be a random thing, but needs to tie to the owner
>entity (yet still be unique between entities).  Can we say that the
>owner entity can suggest an Owner ID?
>
>Joe

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

Message: 4
Date: Fri, 6 Mar 2015 18:39:46 +0000
From: Kent Watsen <[email-masked]>
To: t.petch <[email-masked]>, "[email-masked]"
	<[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] Fw: 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
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Hi Tom and Juergen,

Thank you for all your comments so far.  I will more fully engage in this
thread after the draft submission deadline has past.  I just wanted to let
you know why I haven't replied yet.

Thanks again,
Kent

On 3/6/15, 11:59 AM, "t.petch" <[email-masked]> wrote:

>
> I have read, and re-read and re-read ... section 3.2 of call-home and I
> am struggling.  I am reminded of rfc5539bis where we started out with
> something similar and ended up with
> "  The NETCONF client MUST check the identity of the server according
>to
>    Section 6 of [RFC6125]."
> which I think was a great idea.
>
> We cannot go quite that far with the call-home I-D but think we should
> be
> heading in that direction.
>
> Surely all we need to say, in essence, is that because the server has
> initiated the connection then we have no reference identity and so
> RFC6125 cannot apply.  Therefore the client must be preconfigured with
> whatever it will trust from the server, be that a certificate or a host
> key.  And it should be the certificate of the server; a CA certificate
> on
> its own is not enough since, as we have said already, we have no
> reference identity so knowing that the end user certificate chains back
> to a valid CA is not enough (in general).
>
> And yes, preconfiguring information is a pain but if you want security,
> you have to do it.
>
> So along those lines I offer a new 3.2
>
> ====================================================
> 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.
>
> Which is all the comments I currently have on
> draft-ietf-netconf-call-home-04.
>
> 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,
>>
>> 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
>>
>> --=====2634486923681469604=-
>>
>
>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

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

Subject: Digest Footer

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

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

End of Netconf Digest, Vol 85, Issue 9
**************************************

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2015 10:43:43 +0100

> 1) In the normal Client-Server model, Client connects and Server accepts connections. But in this case, the Client has to connect and also accept connections. The Server has to connect and also acc…

With call home, the server connects to the client (so there needs to
be a daemon accepting incoming connections) but then roles are swapped
and the same connection is used to run either SSH or TLS over it.
 
> 2) Consider a case where in my management element has multiple IPs, how will the Network element know which IP to connect to ? How will it know the management element's IP ?

There once was an ID proposing DHCP options for this... One could
perhaps also play with DNS SRV records. I think the question how you
learn where to call home is outside of the call home mechanism itself.

> Applicable to NETCONF also ? Can those pain points be resolved as part of this draft?

I think it would help if you can describe what the pain points are
that you see. Otherwise, this is open ended and not actionable.

/js

---

From: Rohit R Ranade <[email-masked]>
Date: Mon, 9 Mar 2015 10:05:18 +0000

Hi,

##
##

About the above statement, does it mean that after Server connects to the client, the client will initiate the authorization process as if it connected to the Server ?

My pain point about the mixing of Client and Server features is that if a module based architecture is considered where NETCONFS sits above SSHS and NETCONFC sits above SSHC.
1) NETCONFS will have to sit above SSHS and SSHC (Since all socket and authorization related info will be handled by SSHS and its underlying layers).
2) NETCONFS at Network element and at Management element will be slightly different (one with call home, one without). Its dependency with underlying modules will also be dependent on whether the device is NE or management element.

With Regards,
Rohit

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 09 March, 2015 15:14
To: Rohit R Ranade
Cc: [email-masked]
Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04

 

/js

---

From: t.petch <[email-masked]>
Date: Mon, 9 Mar 2015 10:29:15 +0000

----- Original Message -----
From: "Rohit R Ranade" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 09, 2015 5:50 AM
>
> I have a scenario where in my network element comes up and My
management element needs to know when it comes up.
> 1) In the normal Client-Server model, Client connects and Server
accepts connections. But in this case, the Client has to connect and
also accept connections. The Server has to connect and also accept
connections. The NETCONF Server will have to depend on SSHS and SSHC .
The NETCONF Client will have to depend on both SSHS and SSHC. This I
feel is not right.
>
> 2) Consider a case where in my management element has multiple IPs,
how will the Network element know which IP to connect to ? How will it
know the management element's IP ?
>
> 3) Currently is there any other Protocol where in this feature of
intermixing of Client and Server features has been done ? Are the pain
points of those implementations

Rohit

The idea of an internet host being both client and server has been
around for decades, with protocols such as mail, FTP, HTTP ... and SNMP.
I used to wonder how it was done and then I learnt about TCP and UDP
port numbers and all became clear.

But that is not what is happening here and if you think it is, then I
would be interested to hear which bit of call-home is creating that
impression.

Here, the NMS is always the NETCONF client, the network element is
always the NETCONF server, so at the application level, nothing is
reversed. Likewise at the SSH (or TLS) level, nothing is reversed.  It
is only at the TCP level that a reverse takes place, that the network
element is now the TCP client requesting a TCP connection of the NMS as
TCP server, after which, normal SSH (or TLS) service resumes.

As to finding one or more IP addresses for the NMS, well, it has to be
discovered or configured, as ever.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2015 11:43:24 +0100

> About the above statement, does it mean that after Server connects to the client, the client will initiate the authorization process as if it connected to the Server ?

This is my understanding.
 
> 2) NETCONFS at Network element and at Management element will be slightly different (one with call home, one without). Its dependency with underlying modules will also be dependent on whether the d…

Quoting from the Introduction:

   Both NETCONF Call Home and RESTCONF Call Home preserve the client/
   server roles of underlying transport, as when compared to standard
   NETCONF and RESTCONF connections.  Specifically, regardless if call
   home is used or not, the SSH and TLS client/server roles are the
   same.

I think this answers 1). I do not understand 2).

/js

---

From: Rohit R Ranade <[email-masked]>
Date: Mon, 9 Mar 2015 12:00:03 +0000

Hi,

After your explanation of reversing at the TCP level it is quite clear. For a first time reader of this draft, it was not very clear.
But, it will still impact the state-machines of NETCONFS, SSHS and SSHC. I think this impact is OK, considering the benefits.
Maybe the draft can be updated about the changes in the state-machines with a clear diagram. 

With Regards,
Rohit

-----Original Message-----
From: t.petch [mailto:[email-masked]] 
Sent: 09 March, 2015 15:59
To: Rohit R Ranade; [email-masked]
Subject: Re: [Netconf] Few points about draft-ietf-netconf-call-home-04

----- Original Message -----
From: "Rohit R Ranade" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 09, 2015 5:50 AM

Rohit

Tom Petch