Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans

[Alan DeKok]

On May 16, 2017, at 4:06 PM, Douglas Gash (dcmgash)  wrote:
> Many items are marked with just [Agree], if it seems there is a trivial way 
> to adjust according to the comment.

  Thanks.  I'll comment on things I have comments on, and remove everything 
else.

> 3.5 ...
>  
>   - Unused fixed length fields SHOULD have values of zero.
>  
> * what happens when they don't?  I suggest adding text saying that the
> fields are ignored.
> [Agree, changed text to: "To signal that any variable length data fields are 
> unused, their
>   length value is set to zero." As to what happens when fields are 
> unused, this will depend upon the fields]

  I meant what happens when an unused field has a non-zero length?

  If the field is unused, the spec should say the field is ignored, and treated 
as if it did not exist.

> ...  This document does not discuss the management and storage of
>those keys.  ...
>  
> * there should be some discussion in the Security Considerations section
> about this.  Otherwise, this subject will be brought up in the security
> review.
> [Will be happy to stand corrected, but that strikes me as both outside the 
> documentation of the protocol, and likely to lock in practices that will 
> become out-of-date.]

  The draft should also document recommended practices for how to use the 
protocol, such as how keys should be managed / generated / stored.

   i.e. "As the security of the obfuscation method is unknown, keys SHOULD be 
produced via a CSPRNG, keys SHOULD be different for every client/server pair", 
etc.

  The original RADIUS RFC used a secret key, but didn't forbid a key of zero 
length.  I ran into at least one vendor who didn't allow for the entry of 
secret keys, and always set it to a zero-length string.  The next rev of the 
RFC forbade that...

>   ...  It is an implementation detail of the server and client,
>as to whether they will maintain only one key, or a different key for
>each client or server with which they communicate.  For security
>reasons, the latter options MUST be available, but it is a site
>dependent decision as to whether the use of separate keys is
>appropriate.
>  
> * those sentences seem to disagree with each other.  It's an
> "implementation detail", but it MUST be supported.  I suggest requiring
> the capability of per-server and per-client keys.
> [Agree, the requirements must be supported by implementations, however we 
> leave it for the implementor as to whether this is used]

  The wording is awkward.  Perhaps "client implementations MUST support 
per-server keys, and server implementations MUST support per-client keys".

  The sentence on "site dependent decision" can probably be removed.  Or maybe 
replaced with a suggestion that "using the same key for multiple hosts is NOT 
RECOMMENDED"

> * This last sentence is confusing.  Are there different secrets for
> different packets in one TCP stream?  If so, nothing in the document says
> so.  If not, then there is every reason to believe that the secret is
> mismatched. And, the *next* packet will decrypt incorrectly.  Which means
> (again) you might as well just close the TCP connection.
> [though we would not want to restrict to a single secret on server for a 
> client, we can restrict the clint that it should us just a single secret on a 
> client at a time for a connection to a server. This would mean that we could 
> not have single connect, multi session interaction from a client with 
> multiple secrets so then we could close the connection]

  I'm not sure what that means...

  It should say that the same key is used for the lifetime of a TCP connection. 
 Though the keys can be changed in between TCP connections.

  And, if there's a key mismatch, all bets are off, and the TCP connection is 
closed.

>This is a standard ASCII authentication.  The START packet may
>contain the username, but need not do so.
>  
> * what happens when the username is / is-not included?  i.e. what do
> implementations *do*?
> [Agreed to expand. the server can of course, finish the session at any time, 
> as detailed in the "session termination" section. But let's assume that we 
> want the server to carry on the process, then it will retrieve the username 
> as described in the following proposed text: "The START packet MAY
>contain the username.  If the user does not include the username then
>the server MAY obtain it from the client with a CONTINUE
>TAC_PLUS_AUTHEN_STATUS_GETUSER.  When the server has the username, it
>will obtain the password using a continue with
>TAC_PLUS_AUTHEN_STATUS_GETPASS.  ASCII login uses the user_msg field
>for both the username and password.  The data fields in both the
>START and CONTINUE packets are not used for ASCII logins, any content
>MUST be ignored.  The session is composed of a single START followed
>by zero or more pairs of REPLYs and CONTINUEs, followed by a final
>

Re: [OPSAWG] LC request//RE: I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-09.txt

[Duzongpeng]

Hi Tianran,

Thanks for your question.

This draft describes the scenario that, on the date plane, the WTP is connected 
to an AR instead of AC by using some kind of tunnel mechanisms. And this I-D 
describes several tunnel options. It will benefit the interworking of WTP and 
AC when this alt-tunnel network infrastructure is used.

As far as I know, Huawei, Cisco and ALU partially implemented the proposed 
solution(please correct me if my information is wrong ;-)). I.e., each of the 
vendors supports one or more tunnel types, while the full set is not necessary.


Best Regards
Zongpeng Du

-Original Message-
From: Tianran Zhou 
Sent: Tuesday, May 16, 2017 2:12 PM
To: Duzongpeng; opsawg@ietf.org
Subject: RE: [OPSAWG] LC request//RE: I-D Action: 
draft-ietf-opsawg-capwap-alt-tunnel-09.txt

Hi Zongpeng,

Thank you very much for picking this work up. The new version has a significant 
improvement on addressing existing comments.
One more question that many people may be interested. Whether this I-D has been 
implemented or has plan to be implemented and deployed?

Best,
Tianran

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Duzongpeng
> Sent: Monday, May 15, 2017 5:56 PM
> To: opsawg@ietf.org
> Subject: [OPSAWG] LC request//RE: I-D Action:
> draft-ietf-opsawg-capwap-alt-tunnel-09.txt
> 
> Hi All,
> 
> I am happy to join the I-D draft-ietf-opsawg-capwap-alt-tunnel, and 
> help to improve the document based on the comments received and 
> recorded in this page
> (https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel)
> .
> 
> I revised the document and responded to all the existing comments as 
> listed in the attachments. Also thanks Joe Touch's comments, which I 
> have solved in the document. The major change include:
> 1. At the security aspect, we suggest using the IPSec to protect the 
> data tunnel between WTP and AR.
> 2. Add a new sub-element, "minimum IPv6 MTU", according to the 
> suggestion from Joe Touch.
> 3. Make it clear that "IEEE 802.11 WTP Alternate Tunnel Failure Indication"
> is carried in "CAPWAP Station Configuration Request message".
> 4. Make it clear that we define seven sub-elements (each with its 
> corresponding type number). Three of them are specific for CAPWAP, one 
> is specific for GRE, and others are common ones. Make it clear that 
> they can only be used as sub-elements of "Alternate Tunnel 
> Encapsulations Type message element" and "IEEE 802.11 WTP Alternate 
> Tunnel Failure Indication message element".
> 5. Change the structure of the draft. Firstly, introduce the three new 
> "message element"; secondly, introduce the three tunnel types; 
> finnaly, introduce the seven sub-elements involved.
> 6. Give more explanations to the GRE tunnel type.
> 
> Now I believe this document is ready to send to IESG. So I request for 
> a WGLC. And I will also help to reply any comments/questions during 
> the following procedure.
> 
> Regards,
> Zongpeng
> 
> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of 
> internet-dra...@ietf.org
> Sent: Thursday, May 04, 2017 10:46 AM
> To: i-d-annou...@ietf.org
> Cc: opsawg@ietf.org
> Subject: [OPSAWG] I-D Action: 
> draft-ietf-opsawg-capwap-alt-tunnel-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Operations and Management Area 
> Working Group of the IETF.
> 
> Title   : Alternate Tunnel Encapsulation for Data Frames in
> CAPWAP
> Authors : Rong Zhang
>   Rajesh S. Pazhyannur
>   Sri Gundavelli
>   Zhen Cao
>   Hui Deng
>   Zongpeng Du
>   Filename: draft-ietf-opsawg-capwap-alt-tunnel-09.txt
>   Pages   : 26
>   Date: 2017-05-03
> 
> Abstract:
>Control and Provisioning of Wireless Access Points (CAPWAP) defines a
>specification to encapsulate a station's data frames between the
>Wireless Transmission Point (WTP) and Access Controller (AC).
>Specifically, the station's IEEE 802.11 data frames can be either
>locally bridged or tunneled to the AC.  When tunneled, a CAPWAP data
>channel is used for tunneling.  In many deployments encapsulating
>data frames to an entity other than the AC (for example to an Access
>Router (AR)) is desirable.  Furthermore, it may also be desirable to
>use different tunnel encapsulation modes between the WTP and the
>Access Router.  This document defines extension to CAPWAP protocol
>for supporting this capability and refers to it as alternate tunnel
>encapsulation.  The alternate tunnel encapsulation allows 1) the WTP
>to tunnel non-management data frames to an endpoint different from
>the AC and 2) the WTP to tunnel using one of many known encapsulation
>types such as IP-IP,