Subject: review of draft-ietf-netconf-tls-01

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Mar 2008 16:33:09 +0100

My comments on draft-ietf-netconf-tls-01:

- General: Reasonable document, but I am not sure the password
  authentication fits the RADIUS requirements

- I read:

     When the NETCONF peer processes a closure request of the
     NETCONF connection, it MUST send a TLS close_notify alert before
     closing the connection.

  The phrase "processes a closure request of the NETCONF connection"
  sounds fuzzy to me. Perhaps you mean this:

     When the NETCONF peer closes the NETCONF connection, it MUST send
     a TLS close_notify alert before closing the TCP connection.

  I note that there might be cases where this is not possible, e.g.
  the peer is dying before if gets to say good bye.

- I read:

     Unless some other fatal alert has been transmitted, ...

  Who is transmitting a fatal alert to whom and how? Perhaps you mean:

     Unless a fatal error has occured, ...

- What is the 'write side' of a connection?

- Second sentence in section 3. seems to be garbled.

- Can the password based authentication scheme be hooked into RADIUS?

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 18 Mar 2008 11:10:30 +0100

Dear Juergen,

Thank you for your comments. Please see comments in-line..

<snip>
>      a TLS close_notify alert before closing the TCP connection.

OK, I will adopt this text.

>   the peer is dying before if gets to say good bye.

IMO, it is application behavior, RFC 4741 says:

      "The session closure may be explicitly
       performed by the client, or implicitly performed by the server
       based on criteria such as failure of the underlying transport, or
       simple inactivity timeout.  This criteria is dependent on the
       implementation and the underlying transport."

>      Unless a fatal error has occured, ...

Yes. And fatat alert may be sent by both of the agent and the manager.

> - What is the 'write side' of a connection?

RFC4346 uses this terminology of read and the write directions and 
sides. Each entity has a write and read buffers. When a close is sent by 
an entity, the entity will close the write buffer (write side of the 
connection), meaning that it will not send more data over the TLS session.

> - Second sentence in section 3. seems to be garbled.

It is replaced with

    This document specifies how to use TLS with endpoint authentication,
    which can be based on either preshared keys [RFC4279] or public key
    certificates [RFC4346].

> - Can the password based authentication scheme be hooked into RADIUS?

For the momenet it doesn't, and this was the discussion in last meeting. 
I hope we can move forward with one of the presented options.

> /js

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

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

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 18 Mar 2008 11:10:30 +0100

Dear Juergen,

<snip>

It is replaced with

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Mar 2008 11:57:01 +0100

On Tue, Mar 18, 2008 at 11:10:30AM +0100, Mohamad Badra wrote:

> RFC4346 uses this terminology of read and the write directions and sides. 
> Each entity has a write and read buffers. When a close is sent by an 
> entity, the entity will close the write buffer (write side of the 

I guess it will help readers if you make it clear where you use TLS
specific terms and where the definition of these terms can be found.
I at least got confused by terminology issues.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 18 Mar 2008 11:57:01 +0100

/js