Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 25 Sep 2008 11:44:07 +0200

> Hi All, 
> as discussed in the NETCONF session Badra initiated 
> the review of the security AD Pasi and updated the 
> draft NETCONF over TLS based on the recommendations 
> in the session and Pasi's review comments (see 
> http://tools.ietf.org/html/draft-ietf-netconf-tls-04 and
> http://www.ietf.org/mail-archive/web/netconf/current/msg03743.html). 
> With this mail we want to start a WGLC for the draft 
> NETCONF over TLS, which is proposed to publish as a 
> Proposed Standard RFC. 
> 
> The WGLC starts on September 25, 2008 and will run 
> until October 10, 2008. 
> Unfortunately there were no additional comments on 
> the last version of the draft on the maillist. 
> We definitely want to be sure whether we have sufficient 
> WG support for the document or not. 
> 
> PLEASE REVIEW and comment it. Even if you don't have 
any technical comments PLEASE SPEAK UP AND STATE 
whether you support it or not!
> Thank you and looking forward for your reviews and 
> comments. 
> 
> Mehmet & Bert
> 
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Sep 2008 10:17:14 +0200

On Thu, Sep 25, 2008 at 11:44:07AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:

> With this mail we want to start a WGLC for the draft NETCONF over
> TLS, which is proposed to publish as a Proposed Standard RFC.

I have read <draft-ietf-netconf-tls-04.txt> and here are my comments:

a) I am wondering about PSK support. RFC 4279 says in the
   applicability statement:

     The ciphersuites defined in this document are intended for a rather
     limited set of applications, usually involving only a very small
     number of clients and servers.  Even in such environments, other
     alternatives may be more appropriate.

   With NETMOD deployed on many bridges and routers and some host
   systems in the future, we might have a small number of clients with
   a large number of sFrom [email-masked]  Fri Sep 26 01:17:21 2008
Date: Fri, 26 Sep 2008 10:17:14 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>,
	[email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
Reply-To: [email-masked]
Sender: [email-masked]

On Thu, Sep 25, 2008 at 11:44:07AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote:

> With this mail we want to start a WGLC for the draft NETCONF over
> TLS, which is proposed to publish as a Proposed Standard RFC.

I have read <draft-ietf-netconf-tls-04.txt> and here are my comments:

a) I am wondering about PSK support. RFC 4279 says in the
   applicability statement:

     The ciphersuites defined in this document are intended for a rather
     limited set of applications, usually involving only a very small
     number of clients and servers.  Even in such environments, other
     alternatives may be more appropriate.

   With NETMOD deployed on many bridges and routers and some host
   systems in the future, we might have a small number of clients with
   a large numbeervers and a key management problem.

b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA
   (please add a reference to RFC 4279 where this cipher suite is
   defined to help the reader) but does not spell out any other cipher
   suite requirement, essentially making
   TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps
   there needs to be more text about required to implement cipher
   suites or pointers to "standard" required to implement TLS cipher
   suites that apply here as well.

c) I suggest to remove "simple" from the text in the introduction.

d) What does "highly recommended" mean in terms of IETF terminology?
   Is this the same as RECOMMENDED? I suggest to stick to the well
   defined and understood IETF terminology.

Summary: I think the document has improved quite a bit since its early
days. I am still not 100% convinced about the PSK support and it being
required to implement.

/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/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

r of servers and a key management problem.

b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA
   (please add a reference to RFC 4279 where this cipher suite is
   defined to help the reader) but does not spell out any other cipher
   suite requirement, essentially making
   TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps
   there needs to be more text about required to implement cipher
   suites or pointers to "standard" required to implement TLS cipher
   suites that apply here as well.

c) I suggest to remove "simple" from the text in the introduction.

d) What does "highly recommended" mean in terms of IETF terminology?
   Is this the same as RECOMMENDED? I suggest to stick to the well
   defined and understood IETF terminology.

Summary: I think the document has improved quite a bit since its early
days. I am still not 100% convinced about the PSK support and it being
required to implement.

/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/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Sat, 27 Sep 2008 14:05:51 +0800

Hi,
in section 2, it says,
"The other party MUST respond with a close_notify alert of
its own and close down the connection immediately, discarding any
pending writes"
I wanna ask why immediately instead of sending pening writes before close down the connection.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Sat, 27 Sep 2008 14:05:51 +0800

Hi,
in section 2, it says,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2008 11:06:22 +0200

> close down the connection.

And I like to add whether it is normal practice that the TLS teardown
procedure is application protocol specific. RFC 5246 section 7.2.1
discusses closure alerts in TLS 1.2 and I like to understand why we
need additional text for NETCONF over TLS.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 BremeFrom [email-masked]  Sat Sep 27 02:06:24 2008
Date: Sat, 27 Sep 2008 11:06:22 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: fanhuaxiang 90002624 <[email-masked]>
Mail-Followup-To: fanhuaxiang 90002624 <[email-masked]>,
	"Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>,
	[email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt
Reply-To: [email-masked]
Sender: [email-masked]

> close down the connection.

And I like to add whether it is normal practice that the TLS teardown
procedure is application protocol specific. RFC 5246 section 7.2.1
discusses closure alerts in TLS 1.2 and I like to understand why we
need additional text for NETCONF over TLS.

/js

Phone: +49 421 200 3587         Campus Ring 1, 28759n, Germany

 Bremen, Germany

---

From: [email-masked]
Date: Sat, 27 Sep 2008 15:49:33 +0200 (CEST)

> need additional text for NETCONF over TLS.

I think we should correct that. What about adopting the text of section
4.4 of syslog-tls
(http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt).

   "A TLS client MUST close the associated TLS connection if the
   connection is not expected to deliver any NETCONF messages later.  It
   MUST send a TLS close_notify alert before closing the connection.  A
   client MAY choose to not wait for the server's close_notify alert and
   simply close the connection, thus generating an incomplete close on
   the seFrom [email-masked]  Sat Sep 27 07:16:16 2008
Date: Sat, 27 Sep 2008 15:49:33 +0200 (CEST)
From: [email-masked]
To: [email-masked]
Importance: Normal
Cc: =?utf-8?Q?=C2?= <[email-masked]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?=
 =?utf-8?q?conf-t__ls-04=2Etxt?=
Sender: [email-masked]

> need additional text for NETCONF over TLS.

I think we should correct that. What about adopting the text of section
4.4 of syslog-tls
(http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt).

   "A TLS client MUST close the associated TLS connection if the
   connection is not expected to deliver any NETCONF messages later.  It
   MUST send a TLS close_notify alert before closing the connection.  A
   client MAY choose to not wait for the server's close_notify alert and
   simply close the connection, thus generating an incomplete close on
   rver side.  Once the server gets a close_notify from the
   client, it MUST reply with a close_notify unless it becomes aware
   that the connection has already been closed by the client (e.g., the
   closure was indicated by TCP).

   When no data is received from a connection for a long time (where the
   application decides what "long" means), a server MAY close the
   connection.  The server MUST attempt to initiate an exchange of
   close_notify alerts with the client before closing the connection.
   Servers that are unprepared to receive any more data MAY close the
   connection after sending the close_notify alert, thus generating an
   incomplete close on the client side.  When the client has received
   the close_notify alert from the server and still has pending data to
   send, it SHOULD send the pending data before sending the close_notify
   alert."

Best regards,

the server side.  Once the server gets a close_notify from the
   client, it MUST reply with a close_notify unless it becomes aware
   that the connection has already been closed by the client (e.g., the
   closure was indicated by TCP).

   When no data is received from a connection for a long time (where the
   application decides what "long" means), a server MAY close the
   connection.  The server MUST attempt to initiate an exchange of
   close_notify alerts with the client before closing the connection.
   Servers that are unprepared to receive any more data MAY close the
   connection after sending the close_notify alert, thus generating an
   incomplete close on the client side.  When the client has received
   the close_notify alert from the server and still has pending data to
   send, it SHOULD send the pending data before sending the close_notify
   alert."

Best regards,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2008 17:41:19 +0200

On Sat, Sep 27, 2008 at 03:49:33PM +0200, [email-masked] wrote:
> 4.4 of syslogFrom [email-masked]  Sat Sep 27 08:52:32 2008
Date: Sat, 27 Sep 2008 17:41:19 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked],
	fanhuaxiang? 90002624? <[email-masked]>, ? <[email-masked]>
Cc: ? <[email-masked]>
Subject: Re: [Netconf] ????WGLC??for??draft-ietf-netconf-t ls-04.txt
Reply-To: [email-masked]
Sender: [email-masked]

On Sat, Sep 27, 2008 at 03:49:33PM +0200, [email-masked] wrote:
> 4.4 of -tls

Can someone explain to me _why_ all this detail is needed? The SSH
transport mapping does not spell how how the SSH teardown is done.
So why do we need to be that specific with TLS?

/js

syslog-tls
>    send, it SHOULD send the pending data before sending the close_notify

Can someone explain to me _why_ all this detail is needed? The SSH
transport mapping does not spell how how the SSH teardown is done.
So why do we need to be that specific with TLS?

/js

---

From: [email-masked]
Date: Sat, 27 Sep 2008 17:53:29 +0200 (CEST)

> So why do we need to be that specific with TLS?

Well, I think we can find the same text in all "Application over TLS"
documents, and there was no objection on integrating such text in those
documents, which can IMO improve the readability.

Please don't hesitate to propose your text (to the Connection Closure
Section) if you prefer to don't have this detail.

Best regards
Badra

---

From: [email-masked]
Date: Sat, 27 Sep 2008 17:53:29 +0200 (CEST)

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2008 18:14:32 +0200

> documents, which can IMO improve the readability.

This does not really answer my question. Why is the text in the TLS
specs not sufficient? We should IMHO not include text is the TLS
specifications already cover things.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Sep 2008 18:14:32 +0200

/js

---

From: [email-masked]
Date: Sat, 27 Sep 2008 19:18:05 +0200 (CEST)

> specifications already cover things.

Well, in this case we should remove the last two paragraphs from the
section 2.2. But I don't think it is a good idea.

Keep it as it is will improve the readability. Based on your review on
version 01
(http://www.ops.ietf.org/lists/netconf/netconf.2008/msg00154.html),
Section 2.2 has been detailed as it is today.

Please kindly propose which portion you prefer to read in the document,
and which one you don't.

Best regards,
Badra

---

From: [email-masked]
Date: Sat, 27 Sep 2008 19:18:05 +0200 (CEST)

Best regards,
Badra

---

From: [email-masked]
Date: Sat, 27 Sep 2008 23:29:21 +0200 (CEST)

> specifications already cover things.

Dear Juergen,

What about modify the actual text as follows:

OLD:

2.2. Connection Closure

   Either NETCONF peer MAY stop the NETCONF connection at any time and
   therefore notify the other NETCONF peer that no more data on this
   channel will be sent and that any data received after a closure
   request will be ignored.  This MAY happen when no data is received
   from a connection for a long time, where the application decides what
   "long" means.

   TLS has the ability for secure connection closure using the Alert
   protocol.  When the NETCONF peer closes the NETCONF connection, it
   MUST send a TLS close_notify alert before closing the TCP connection.
   Any data received after a closure alert is ignored.

   Unless a fatal error has occurred, each party is required to send a
   close_notify alert before closing the write side of the connection
   [RFC5246].  TFrom [email-masked]  Sat Sep 27 14:31:24 2008
Date: Sat, 27 Sep 2008 23:29:21 +0200 (CEST)
From: [email-masked]
To: [email-masked]
Importance: Normal
Cc: =?utf-8?Q?=C2?= <[email-masked]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgPz/CoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1u?=
 =?utf-8?q?et_conf-t_=3F=3Fls-04=2Etxt?=
Sender: [email-masked]

> specifications already cover things.

Dear Juergen,

What about modify the actual text as follows:

OLD:

2.2. Connection Closure

   Either NETCONF peer MAY stop the NETCONF connection at any time and
   therefore notify the other NETCONF peer that no more data on this
   channel will be sent and that any data received after a closure
   request will be ignored.  This MAY happen when no data is received
   from a connection for a long time, where the application decides what
   "long" means.

   TLS has the ability for secure connection closure using the Alert
   protocol.  When the NETCONF peer closes the NETCONF connection, it
   MUST send a TLS close_notify alert before closing the TCP connection.
   Any data received after a closure alert is ignored.

   Unless a fatal error has occurred, each party is required to send a
   close_notify alert before closing the write side of the connection
   [RFC524he other party MUST respond with a close_notify alert of
   its own and close down the connection immediately, discarding any
   pending writes.  It is not required for the initiator of the close to
   wait for the responding close_notify alert before closing the read
   side of the connection.

NEW:

2.2. Connection Closure

   TLS [RFC5246] has the ability for secure connection closure using the
   Alert protocol.  Either NETCONF peer MAY stop the NETCONF connection at
   any time by sending a TLS close_notify alert.  This notifies the
   recipient that the sender will not send any more messages on this
   connection.  Any data received after a closure alert is ignored.

Like that, if people need more information on this alert behaviour, they
can refer to TLS document.

Best regards,
Badra

6].  The other party MUST respond with a close_notify alert of
   its own and close down the connection immediately, discarding any
   pending writes.  It is not required for the initiator of the close to
   wait for the responding close_notify alert before closing the read
   side of the connection.

NEW:

2.2. Connection Closure

   TLS [RFC5246] has the ability for secure connection closure using the
   Alert protocol.  Either NETCONF peer MAY stop the NETCONF connection at
   any time by sending a TLS close_notify alert.  This notifies the
   recipient that the sender will not send any more messages on this
   connection.  Any data received after a closure alert is ignored.

Like that, if people need more information on this alert behaviour, they
can refer to TLS document.

Best regards,
Badra

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Sun, 28 Sep 2008 09:09:01 +0800

Hi,
comments inline.
>   TLS has the ability From [email-masked]  Sat Sep 27 18:09:41 2008
Date: Sun, 28 Sep 2008 09:09:01 +0800
From: fanhuaxiang 90002624 <[email-masked]>
To: [email-masked]
Priority: normal
Cc: =?iso-8859-7?Q?=C2?= <[email-masked]>
Subject: [Netconf] =?iso-8859-7?b?IFJlOiBSZTqgPz+gV0dMQ6Bmb3KgZHJhZnQtaWV0?=
 =?iso-8859-7?q?f-net_conf-t=3F=3Fls-04=2Etxt?=
Sender: [email-masked]

Hi,
comments inline.
>   TLS has the abfor secure connection closure using the Alert
>   MUST send a TLS close_notify alert before closing the TCP 
>   [RFC5246].  The other party MUST respond with a close_notify 
> alert of
IMHO, we may need to describe when to close connection for both sides.e.g, when client don't want to initial any rpc operation or server found there is no data on the wire for a long time.
And, I wanna express there is a difference between syslog and netconf scenarios. in syslog case, only client is expected to send data, so syslog-tls says "client SHOULD send the pending data before sending the close_notify alert", whilst in netconf case, both sides are expected to send data, so the same words should be applied to client and server.

washam

ility for secure connection closure using the Alert
>   MUST send a TLS close_notify alert before closing the TCP 
>   [RFC5246].  The other party MUST respond with a close_notify 
> alert of
IMHO, we may need to describe when to close connection for both sides.e.g, when client don't want to initial any rpc operation or server found there is no data on the wire for a long time.
And, I wanna express there is a difference between syslog and netconf scenarios. in syslog case, only client is expected to send data, so syslog-tls says "client SHOULD send the pending data before sending the close_notify alert", whilst in netconf case, both sides are expected to send data, so the same words should be applied to client and server.

washam

---

From: [email-masked]
Date: Sun, 28 Sep 2008 03:34:07 +0200 (CEST)

Dear Washam,

> IMHO, we may need to describe when to close connection for both sides.e.g,
> when client don't want to initial any rpc operation or server found there
> is no data on the wire for a long time.
> And, I wanna express there is a difference between syslog and netconf
> scenarios. in syslog case, only client is expected to send data, so
> syslog-tls says "client SHOULD send the pending data before sending the
> close_notify alert", whilst in netconf case, both sides are expected to
> send data, so the same words should be applied to client and server.

Let's agree on a common text, please don't hesitate to propose your text
if the following isn't sufficient for you or if more correction is needed.

2.2. Connection Closure

   TLS [RFC5246] has the ability for secure connection closure using the
   Alert protocol.  Either NETCONF peer MAY stop the NETCONF connection at
   any time by sending a TLS close_notify alert.

   A NETCONF peer MUST close the associated TLS connection if the
   connection is not expected to deliver any rpc operation or when no data
   is received from a connection for a long time, where the application
   decides what "long" means.  The NETCONF peer MUST send a TLS
   close_notify alert before closing the connection.  A sender's
   close_notify MAY choose to not wait for the receiver's close_notify
   alert and simply close the connection, thus generating an incomplete
   close on the receiver's close_notify side.  Once the receiver gets a
   close_notify from the sender's close_notify, it MUST reply with a
   close_notify unless it becomes aware that the connection has already
   been closed by the sender (e.g., the closure was indicated by TCP).

Best regards,
Badra

---

From: [email-masked]
Date: Sun, 28 Sep 2008 03:34:07 +0200 (CEST)

Dear Washam,

2.2. Connection Closure

Best regards,
Badra

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Sun, 28 Sep 2008 13:27:29 +0800

Hi,
>   is received from a connection for a long time, where the 
> application   decides what "long" means.  The NETCONF peer MUST 
> send a TLS
>   close_noFrom [email-masked]  Sat Sep 27 22:27:33 2008
Date: Sun, 28 Sep 2008 13:27:29 +0800

Hi,
>   is received from a connection for a long time, where the 
> application   decides what "long" means.  The NETCONF peer MUST 
> send a TLS
>   close_notify atify alert before closing the connection.  A sender's
>   alert and simply close the connection, thus generating an 
> incomplete   close on the receiver's close_notify side.  Once the 
> receiver gets a
>   close_notify unless it becomes aware that the connection has 
> already   been closed by the sender (e.g., the closure was 
> indicated by TCP).
I'd like add below sentence to the end of the paragraph.
"in the case receiver still has pending data to send, it SHOULD send the pending data before sending the close_notify alert."

lert before closing the connection.  A sender's
>   alert and simply close the connection, thus generating an 
> incomplete   close on the receiver's close_notify side.  Once the 
> receiver gets a
>   close_notify unless it becomes aware that the connection has 
> already   been closed by the sender (e.g., the closure was 
> indicated by TCP).
I'd like add below sentence to the end of the paragraph.
"in the case receiver still has pending data to send, it SHOULD send the pending data before sending the close_notify alert."

---

From: [email-masked]
Date: Sun, 28 Sep 2008 12:22:51 +0200 (CEST)

Dear Washam,

Thank you for your reply.
Here is the last text we agree on.
Dear Juergen, based on Washam's comments, I think we need to keep such a
text even if TLS describes this alert.

2.2. Connection Closure

   A NETCONF peer MUST close the associated TLS connection if the
   connection is not expected to deliver any rpc operation or when no data
   is received from a connection for a long time, where the application
   decides what "long" means.  The NETCONF peer MUST send a TLS
   close_notify alert before closing the connection.  A sender's
   close_notify MAY choose to not wait for the receiver's close_notify
   alert and simply close the conneFrom [email-masked]  Sun Sep 28 03:24:08 2008
Date: Sun, 28 Sep 2008 12:22:51 +0200 (CEST)
From: [email-masked]
To: =?utf-8?Q?fanhuaxiang=C2_90002624=C2?= <[email-masked]>
Importance: Normal
Cc: =?utf-8?Q?=C2?= <[email-masked]>
Subject: [Netconf] =?utf-8?b?IFJlOsKgUmU6wqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYt?=
 =?utf-8?q?netcon__f-tls-04=2Etxt?=
Sender: [email-masked]

Dear Washam,

Thank you for your reply.
Here is the last text we agree on.
Dear Juergen, based on Washam's comments, I think we need to keep such a
text even if TLS describes this alert.

2.2. Connection Closure

   A NETCONF peer MUST close the associated TLS connection if the
   connection is not expected to deliver any rpc operation or when no data
   is received from a connection for a long time, where the application
   decides what "long" means.  The NETCONF peer MUST send a TLS
   close_notify alert before closing the connection.  A sender's
   close_notify MAY choose to not wait for the receiver's close_notify
   alert and simply close the connection, thus generating an incomplete
   close on the receiver's close_notify side.  Once the receiver gets a
   close_notify from the sender's close_notify, it MUST reply with a
   close_notify unless it becomes aware that the connection has already
   been closed by the sender (e.g., the closure was indicated by TCP). In
   the case the receiver still has pending data to send, it SHOULD send
   the pending data before sending the close_notify alert.

Best regards,
Badra

ction, thus generating an incomplete
   close on the receiver's close_notify side.  Once the receiver gets a
   close_notify from the sender's close_notify, it MUST reply with a
   close_notify unless it becomes aware that the connection has already
   been closed by the sender (e.g., the closure was indicated by TCP). In
   the case the receiver still has pending data to send, it SHOULD send
   the pending data before sending the close_notify alert.

Best regards,
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Sep 2008 12:13:40 +0200

On Sun, Sep 28, 2008 at 12:22:51PM +0200, [email-masked] wrote:

>    decides what "long" means.

I don't really see the value of this sentence. Essentially the text
says "an application MUST close the TLS connection if the application
believes the TLS connection is not used anymore" - something rather
obvious and I am not sure an explicit MUST is needed.

>    The NETCONF peer MUST send a TLS close_notify alert before
>    closing the connection.

But I think you can't rely on being able to do this in all cases.
Perhaps this should be a SHOULD instead of a MUST.

>    A sender's

See above - I assume a SHOULD is more appropriate than a MUST.

>    In the case the receiver still has pending data to send, it
>    SHOULD send the pending data before sending the close_notify
>    alert.

Here I agree with the SHOULD. ;-)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Sep 2008 12:13:40 +0200

/js

---

From: "tom.petch" <[email-masked]>
Date: Mon, 29 Sep 2008 11:10:26 +0200

----- Original Message -----
From: <[email-masked]>
To: "fanhuaxiangÂ 90002624Â" <[email-masked]>
Cc: "Â" <[email-masked]>
Sent: Sunday, September 28, 2008 12:22 PM
Subject: [Netconf] Re:Â Re:Â WGLCÂ forÂ draft-ietf-netcon f-tls-04.txt

>    the pending data before sending the close_notify alert.

To quote TLS,
"The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes. "
so this proposed text would appear to contradict a TLS MUST.  TLS also takes
great care not to bind itself to TCP and not to prescribe the behaviour of the
underlying transport protocol.

And I imagine that this is what Juergen had in mind.  When we start to reproduce
TLS in our own words, we are likely to make things worse (perhaps also known as
the distributed database problem).  And for those with a sense of history, be
aware that the last call on syslog-tls completed precisely two years ago - and
the I-D is still  being revised:-(

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 29 Sep 2008 11:10:26 +0200

----- Original Message -----
From: <[email-masked]>
To: "fanhuaxiangÂ 90002624Â" <[email-masked]>
Cc: "Â" <[email-masked]>
Sent: Sunday, September 28, 2008 12:22 PM
Subject: [Netconf] Re:Â Re:Â WGLCÂ forÂ draft-ietf-netcon f-tls-04.txt

To quote TLS,

Tom Petch

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Mon, 29 Sep 2008 18:34:57 +0800

Hi,
> application>    decides what "long" means.
> 
> believes the TLS connection is not used anymore" - somFrom [email-masked]  Mon Sep 29 03:35:23 2008
Date: Mon, 29 Sep 2008 18:34:57 +0800
From: fanhuaxiang 90002624 <[email-masked]>
To: [email-masked]
Priority: normal
Cc: ? <[email-masked]>
Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt
Sender: [email-masked]

Hi,
> application>    decides what "long" means.
> 
> believes the TLS connection is not used anymore"ething rather
I think the value of section "connection closure" is to describe when and how to end up a connection. so I think maybe we need to elaborate what "TLS connection is not used anymore" means in netconf context.
> Perhaps this should be a SHOULD instead of a MUST.
isn't it what TLS rfc specify how to close a connection?
> >    A sender's
> >    close_notify MAY choose to not wait for the receiver's 
> close_notify>    alert and simply close the connection, thus 
> generating an incomplete
> already>    been closed by the sender (e.g., the closure was 
> indicated by TCP). 
> 

 - something rather
> obvious and I am not sure an explicit MUST is needed.
I think the value of section "connection closure" is to describe when and how to end up a connection. so I think maybe we need to elaborate what "TLS connection is not used anymore" means in netconf context.
> Perhaps this should be a SHOULD instead of a MUST.
isn't it what TLS rfc specify how to close a connection?
> >    A sender's
> >    close_notify MAY choose to not wait for the receiver's 
> close_notify>    alert and simply close the connection, thus 
> generating an incomplete
> already>    been closed by the sender (e.g., the closure was 
> indicated by TCP). 
>

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Mon, 29 Sep 2008 18:44:32 +0800

Hi,

> underlying transport protocol.
maybe what said in counterpart section in syslog-tls  contradict a TLS MUST, too.
> TLS in our own words, we are likFrom [email-masked]  Mon Sep 29 03:45:02 2008
Date: Mon, 29 Sep 2008 18:44:32 +0800
From: fanhuaxiang 90002624 <[email-masked]>
To: "tom.petch" <[email-masked]>
Priority: normal
Cc: ? <[email-masked]>
Subject: Re: [Netconf] ? Re:? WGLC? for? draft-ietf-netcon f-tls-04.txt
Sender: [email-masked]

Hi,

> underlying transport protocol.
maybe what said in counterpart section in syslog-tls  contradict a TLS MUST, too.
> TLS in our own words, we aely to make things worse (perhaps 
> also known as
washam

re likely to make things worse (perhaps 
> also known as
washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Sep 2008 12:52:05 +0200

On Mon, Sep 29, 2008 at 06:34:57PM +0800, fanhuaxiang 90002624 wrote:
 
> I think the value of section "connection closure" is to describe
> when and how to end up a connection. so I think maybe we need to
> elaborate what "TLS connection is not used anymore" means in netconf
> context.

It is the application's decision and hence any discussion is either
pointless or likely getting it wrong.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Sep 2008 12:52:05 +0200

/js

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 29 Sep 2008 13:44:20 +0200

tom.petch wrote:
 >>Juergen Schoenwaelder wrote:
 >>>fanhuaxiang 90002624 wrote:
> To quote TLS,

>>> pointless or likely getting it wrong.

To quote IESG Evaluation on syslog-tls,

   "Section 4.4:
    OLD:
       A TLS client MUST close the associated TLS connection if the
       connection is not expected to deliver any syslog messages later.
       It MUST send a TLS close_notify alert before closing the
       connection.  A client MAY choose to not wait for the server's
       close_noFrom [email-masked]  Mon Sep 29 04:45:50 2008
Date: Mon, 29 Sep 2008 13:44:20 +0200
From: Mohamad Badra <[email-masked]>
To: fanhuaxiang 90002624 <[email-masked]>,
	Juergen Schoenwaelder <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt
Sender: [email-masked]

tom.petch wrote:
 >>Juergen Schoenwaelder wrote:
 >>>fanhuaxiang 90002624 wrote:
> To quote TLS,

>>> pointless or likely getting it wrong.

To quote IESG Evaluation on syslog-tls,

   "Section 4.4:
    OLD:
       A TLS client MUST close the associated TLS connection if the
       connection is not expected to deliver any syslog messages later.
       It MUST send a TLS close_notify alert before closing the
       connection.  A client MAY choose to not wait for the server's
       close_notify atify alert and simply close the connection, thus
       generating an incomplete close on the server side.  Once the
       server gets a close_notify from the client, it MUST reply with a
       close_notify unless it becomes aware that the connection has
       already been closed by the client (e.g., the closure was
       indicated by TCP).
    NEW:
       A transport sender MUST close the associated TLS connection if
       the connection is not expected to deliver any syslog messages
       later.  It MUST send a TLS close_notify alert before closing the
       connection.  A transport sender (TLS client) MAY choose to not
       wait for the transport receiver's close_notify alert and simply
       close the connection, thus generating an incomplete close on the
       transport receiver (TLS server) side.  Once the transport
       receiver gets a close_notify from the transport sender, it MUST
       reply with a close_notify unless it becomes aware that the
       connection has already been closed by the transport sender
       (e.g., the closure was indicated by TCP).

    Section 4.4:
    OLD:
       When no data is received from a connection for a long time
       (where the application decides what "long" means), a server MAY
       close the connection.  The server MUST attempt to initiate an
       exchange of close_notify alerts with the client before closing
       the connection.  Servers that are unprepared to receive any more
       data MAY close the connection after sending the close_notify
       alert, thus generating an incomplete close on the client side.
       When the client has received the close_notify alert from the
       server and still has pending data to send, it SHOULD send the
       pending data before sending the close_notify alert.
    NEW:
       When no data is received from a connection for a long time
       (where the application decides what "long" means), a transport
       receiver MAY close the connection.  The transport receiver (TLS
       server) MUST attempt to initiate an exchange of close_notify
       alerts with the transport sender before closing the connection.
       Transport receivers that are unprepared to receive any more data
       MAY close the connection after sending the close_notify alert,
       thus generating an incomplete close on the transport sender
       side.  When the transport sender (TLS client) has received the
       close_notify alert from the transport receiver and still has
       pending data to send, it SHOULD send the pending data before
       sending the close_notify alert."

I think the above text would appear to contradict a TLS MUST.  Wouldn't?

I also think the above text describes when to close connection for both 
sides. e.g, when the client doesn't want to initial any syslog message 
or when the server found there is no data on the wire for a long time.

With respect to that, I think we should propose a simalar text, a 
modified text is below:

       "A TLS client (NETCONF manager) MUST close the associated TLS
       connection if the connection is not expected to deliver any rpc
       operation later.  It MUST send a TLS close_notify alert before
       closing the connection.  The client MAY choose to not wait for the
       TLS server (NETCONF agent) close_notify alert and simply close the
       connection, thus generating an incomplete close on the server
       side.  Once the server gets a close_notify from the client, it
       MUST reply with a close_notify unless it becomes aware that the
       connection has already been closed by the transport sender (e.g.,
       the closure was indicated by TCP).

       When no data is received from a connection for a long time (where
       the application decides what "long" means), a TLS server MAY close
       the connection.  The TLS server MUST attempt to initiate an
       exchange of close_notify alerts with the transport sender before
       closing the connection. The server that is unprepared to receive
       any more data MAY close the connection after slert and simply close the connection, thus
       generating an incomplete close on the server side.  Once the
       server gets a close_notify from the client, it MUST reply with a
       close_notify unless it becomes aware that the connection has
       already been closed by the client (e.g., the closure was
       indicated by TCP).
    NEW:
       A transport sender MUST close the associated TLS connection if
       the connection is not expected to deliver any syslog messages
       later.  It MUST send a TLS close_notify alert before closing the
       connection.  A transport sender (TLS client) MAY choose to not
       wait for the transport receiver's close_notify alert and simply
       close the connection, thus generating an incomplete close on the
       transport receiver (TLS server) side.  Once the transport
       receiver gets a close_notify from the transport sender, it MUST
       reply with a close_notify unless it becomes aware that the
       connection has already been closed by the transport sender
       (e.g., the closure was indicated by TCP).

    Section 4.4:
    OLD:
       When no data is received from a connection for a long time
       (where the application decides what "long" means), a server MAY
       close the connection.  The server MUST attempt to initiate an
       exchange of close_notify alerts with the client before closing
       the connection.  Servers that are unprepared to receive any more
       data MAY close the connection after sending the close_notify
       alert, thus generating an incomplete close on the client side.
       When the client has received the close_notify alert from the
       server and still has pending data to send, it SHOULD send the
       pending data before sending the close_notify alert.
    NEW:
       When no data is received from a connection for a long time
       (where the application decides what "long" means), a transport
       receiver MAY close the connection.  The transport receiver (TLS
       server) MUST attempt to initiate an exchange of close_notify
       alerts with the transport sender before closing the connection.
       Transport receivers that are unprepared to receive any more data
       MAY close the connection after sending the close_notify alert,
       thus generating an incomplete close on the transport sender
       side.  When the transport sender (TLS client) has received the
       close_notify alert from the transport receiver and still has
       pending data to send, it SHOULD send the pending data before
       sending the close_notify alert."

I think the above text would appear to contradict a TLS MUST.  Wouldn't?

I also think the above text describes when to close connection for both 
sides. e.g, when the client doesn't want to initial any syslog message 
or when the server found there is no data on the wire for a long time.

With respect to that, I think we should propose a simalar text, a 
modified text is below:

       "A TLS client (NETCONF manager) MUST close the associated TLS
       connection if the connection is not expected to deliver any rpc
       operation later.  It MUST send a TLS close_notify alert before
       closing the connection.  The client MAY choose to not wait for the
       TLS server (NETCONF agent) close_notify alert and simply close the
       connection, thus generating an incomplete close on the server
       side.  Once the server gets a close_notify from the client, it
       MUST reply with a close_notify unless it becomes aware that the
       connection has already been closed by the transport sender (e.g.,
       the closure was indicated by TCP).

       When no data is received from a connection for a long time (where
       the application decides what "long" means), a TLS server MAY close
       the connection.  The TLS server MUST attempt to initiate an
       exchange of close_notify alerts with the transport sender before
       closing the connection. The server that is unprepared to receive
       any more data MAY close the connection after sendingending the
       close_notify alert, thus generating an incomplete close on the
       client side.  When the client has received the close_notify alert
       from the server and still has pending data to send, it SHOULD send
       the pending data before sending the close_notify alert."

Comments?
Best regards,
Mohamad Badra
CNRS - LIMOS Laboratory

 the
       close_notify alert, thus generating an incomplete close on the
       client side.  When the client has received the close_notify alert
       from the server and still has pending data to send, it SHOULD send
       the pending data before sending the close_notify alert."

Comments?
Best regards,
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 29 Sep 2008 14:13:33 +0200

My apologies, I forgot to include Washam comments "in netconf case, both 
sides are expected to send data"

So please forget my last text, below is the correct one:

       When no data is received from a connection for a long time (where
       the application decides what "long" means), a NETCONF peer MAY
       close the connection.  The peer MUST attempt to initiate an
       exchange of close_notify alerts with the other NETCONF peer before
       closing the connection. The close_notify's sender that is
       unpreFrom [email-masked]  Mon Sep 29 05:14:20 2008
Date: Mon, 29 Sep 2008 14:13:33 +0200
From: Mohamad Badra <[email-masked]>
To: fanhuaxiang 90002624 <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>, [email-masked]
Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt
Sender: [email-masked]

My apologies, I forgot to include Washam comments "in netconf case, both 
sides are expected to send data"

So please forget my last text, below is the correct one:

       When no data is received from a connection for a long time (where
       the application decides what "long" means), a NETCONF peer MAY
       close the connection.  The peer MUST attempt to initiate an
       exchange of close_notify alerts with the other NETCONF peer before
       closing the connection. The close_notify's sender that is
      pared to receive any more data MAY close the connection after
       sending the close_notify alert, thus generating an incomplete
       close on the close_notify's receiver side.  When the receiver
       has received the close_notify alert from the sender and still has
       pending data to send, it SHOULD send the pending data before
       sending the close_notify alert."

Best regards
Mohamad Badra
CNRS - LIMOS Laboratory

Mohamad Badra a écrit :
>       close_notify alert and simply close the connection, thus
>       MAY close the connection after sending the close_notify  unprepared to receive any more data MAY close the connection after
       sending the close_notify alert, thus generating an incomplete
       close on the close_notify's receiver side.  When the receiver
       has received the close_notify alert from the sender and still has
       pending data to send, it SHOULD send the pending data before
       sending the close_notify alert."

Best regards
Mohamad Badra
CNRS - LIMOS Laboratory

Mohamad Badra a écrit :
>       close_notify alert and simply close the connection, thus
>       any more data MAY close the connection after sending the

alert,
>       any more data MAY close the connection after sending the

---

From: "David Harrington" <[email-masked]>
Date: Mon, 29 Sep 2008 15:10:14 -0400

Hi,

FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review)
has updated that section to make a clearer distinction between the TLS
actions and the application actions. Transport sender and transport
receiver refer to syslog application fuctionality, and they coordinate
the closure actions. 

   A transport sender MUST close the associated TLS connection if the
   connection is not expected to deliver any syslog messages later.
It
   MUST send a TLS close_notify alert before closing the connection.
A
   transport sender (TLS client) MAY choose to not wait for the
   transport receiver's close_notify alert and simply close the
   connection, thus generating an incomplete close on the transport
   receiver (TLS server) side.  Once the transport receiver gets a
   close_notify from the transport sender, it MUST reply with a
   close_notify unless it becomes aware that the connection has
already
   been closed by the transport sender (e.g., the closure was
indicated
   by TCP).

   When no data is received from a connection for a long time (where
the
   application decides what "long" means), a transport receiver MAY
   close the connection.  The transport receiver (TLS server) MUST
   attempt to initiate an exchange of close_notify alerts with the
   transport sender before closing the connection.  Transport
receivers
   that are unprepared to receive any more data MAY close the
connection
   after sending the close_notify alert, thus generating an incomplete
   close on the transport sender side.  When the transport sender (TLS
   client) has received the close_notify alert from the transport
   receiver and still has pending data to send, it SHOULD send the
   pending data before sending the close_notify alert.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Saturday, September 27, 2008 9:50 AM
> Cc: Â
> Subject: [Netconf] Re:  WGLC for draft-ietf-netconf-t ls-04.txt
> 
> >> I wanna ask why immediately instead of sending pening writes
before
> >> close down the connection.
> >
> (where the

---

From: "David Harrington" <[email-masked]>
Date: Mon, 29 Sep 2008 15:10:14 -0400

Hi,

David Harrington
[email-masked]
[email-masked]
[email-masked]

before

---

From: [email-masked]
Date: Mon, 29 Sep 2008 21:58:37 +0200 (CEST)

Hi David,

>    pending data before sending the close_notify alert.

The same text is being used for NETCONF over TLS, with one exception, we
need to describe when to close connection for both sides (when client
doesn't want to initial any rpc operation or when the server found there
is no data on the wire for a long time).

(I sent the text to the mailing list this morning:
http://www.ietf.org/mail-archive/web/netconf/current/msg03838.html)

Best regards,
Badra

---

From: [email-masked]
Date: Mon, 29 Sep 2008 21:58:37 +0200 (CEST)

Hi David,

Best regards,
Badra

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Tue, 30 Sep 2008 21:02:10 +0800

Hi,
>   pending data before sending the close_notify alert.
wouldn't the last sentence contradict what specified in TLS rfc?
> > Cc: ?

---

From: fanhuaxiang 90002624 <[email-masked]>
Date: Tue, 30 Sep 2008 21:02:10 +0800

Hi,