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

[joel jaeggli <[e-mail]>]

On 10/25/16 6:24 AM, Warren Kumari wrote:
> On Tue, Oct 25, 2016 at 2:41 PM, Duzongpeng <[e-mail]> 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

indeed, ipsec has a tendency to only be used by consenting adults on the
basis of prior coordination. if it's a mnadatory component if a design
that cannot be deployed without it, great; if not it smacks of a token
gesture.
>
>>
>> Best Regards
>> Zongpeng Du
>>
>> -----Original Message-----
>> From: OPSAWG [mailto:[e-mail]] On Behalf Of Kathleen Moriarty
>> Sent: Monday, October 24, 2016 12:57 AM
>> To: The IESG
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/opsawg
>
>