Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)

Hi, Warren

	Thanks for your reply. I want to clarify that I am not suggesting users to use IPsec.

	In the draft, the tunnels between the WTP and AR need to be protected, so the IPsec is between the WTP and AR.

	The network provide is responsible for the security of the users, and should deploy the IPSec between the WTP and AR.

	We can suggest to the network providers that it is not a good choice to use unsecured tunnel.
	Also, the network provide should notify the users that the service is unsecured if they choose some unsecured tunnel types.

Best Regards
Zongpeng Du

-----Original Message-----
From: Warren Kumari [mailto:warren@kumari.net] 
Sent: Tuesday, October 25, 2016 9:24 PM
To: Duzongpeng
Cc: Kathleen Moriarty; The IESG; opsawg-chairs@ietf.org; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; opsawg@ietf.org
Subject: Re: [OPSAWG] Kathleen Moriarty's No Objection on draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)

On Tue, Oct 25, 2016 at 2:41 PM, Duzongpeng <duzongpeng@huawei.com> wrote:
> Hello,
>
>         I would like to give some suggestions as below.
>
>         Some operators deploys their WiFi networks with the data channel unsecured, and even for the wireless part, there are some unsecured deployment examples.
>         It is not a good choice; however, it is simpler.
>
>         Of course, some secure ensured methods should also be provided.
>         For the wireless part, IEEE has provided several secure mechanism;
>         For the wireline part, IPsec can be deployed to protect the security.
>
>         Would it be ok for the draft to suggest that IPsec should be deployed if the tunnel type itself is unsecured.

Personally I don't think that this is a useful suggestion -- *who* exactly would you be advising to do this? Users? They don't (and shouldn't have to) read the RFCs. Suggesting something which we know will not be used seems disingenuous - acknowledging that this is a real issue seems better than suggesting something which we know won't be done to users who we know are not reachable.
W

>
>
> Best Regards
> Zongpeng Du
>
> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Kathleen 
> Moriarty
> Sent: Monday, October 24, 2016 12:57 AM
> To: The IESG
> Cc: opsawg-chairs@ietf.org; 
> draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; opsawg@ietf.org
> Subject: [OPSAWG] Kathleen Moriarty's No Objection on 
> draft-ietf-opsawg-capwap-alt-tunnel-08: (with COMMENT)
>
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-opsawg-capwap-alt-tunnel-08: No Objection
>
> When responding, please keep the subject line intact and reply to all 
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I'm surprised to see security is optional and an assertion that RFCs published in 2009 covers everything.  Threats have evolved since then.
> In looking at RFC5415, Section 12.1, I see:
>
>    Within CAPWAP, DTLS is used to secure the link between the WTP and
>    AC.  In addition to securing control messages, it's also a link in
>    this chain of trust for establishing link layer keys.  Consequently,
>    much rests on the security of DTLS.
>
>     In some CAPWAP deployment scenarios, there are two channels between
>    the WTP and AC: the control channel, carrying CAPWAP Control
>    messages, and the data channel, over which client data packets are
>    tunneled between the AC and WTP.  Typically, the control channel is
>    secured by DTLS, while the data channel is not.
>
>    The use of parallel protected and unprotected channels deserves
>    special consideration, but does not create a threat.  There are two
>    potential concerns: attempting to convert protected data into
>    unprotected data and attempting to convert un-protected data into
>    protected data.  These concerns are addressed below.
>
> Wouldn't interception and tampering of that traffic pose a threat?  How about gaining access to the control channel?
>
> While I don't think this is the right draft to make changes for RFC5415, I don't think it's adequate to say the control channel is optional for encryption.  I could see how the data might be handled elsewhere.  The description discusses this as talking to hundreds of thousands of access points, isn't that access a threat?
>
> This draft allows for additional encapsulation methods, we could require encryption for these new encapsulation methods.
>
> This should probably be a discuss, so I would appreciate some discussion on this to see if we have option here or if something will change in the referenced RFCs soon.
>
> Thank you.
>
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf