Subject: [Softwires] Comments on draft-ietf-softwire-security-requirements-02

From: Yasuhiro SHIRASAKI <[email-masked]>
Date: Mon, 19 Mar 2007 18:57:23 +0900 (JST)

Hi,

I just read the draft and I had some comments as follows:

> 1.  Introduction
>    Layer Two Tunneling Protocol (L2TPv2) selected for "Hubs and Spokes"
>    solution MUST use IPsec if the secure communication is
>    required[RFC3193].  This document provides the implementation
>    guidance (and proper usage) of IPsec as the security protection
>    mechanism by considering the various security vulnerabilities in
>    "Hubs and Spokes" scenarios.  IKEv2 SHOULD be used in the key
>    management protocol for IPsec as the reason of the future proven
>    technology as opposed to IKEv1.

I think it's less important to secure the communication 
of the devices which have direct access to its home carrier
network. therefore I think it's better to clarify that
securing the communication for normadic access scenario
is important by modifying first sentence. e.g.

'For normadic access scenario of "Hubs and Spokes" solution,
using IPsec as described in [RFC3193] is applicable and strongly
desired and recommenced to secure the communication.'

> 3.1.  Deployment Scenarios
>    However, the host device may not always have direct access to its
>    home carrier network, to which the user has subscribed.  For example,
>    the softwire initiator in the laptop PC can access various access
>    networks such as Wi-Fi hot-spots, visited office network.  This is
>    the nomadic case, which the Softwire SHOULD support.

ditto, I think it's better to add the words for clarification.
e.g. 'in this normadic case, using IPsec is strongly desired
and recommended. therefore, IPsec implementation SHOULD be
suppored by the softwire.'

> 3.4.1.1.  PPP Authentication
> 
>    PPP can provide mutual authentication between the SI and SC using
>    CHAP [RFC1994] during the connection establishment phase (Link
>    Control Protocol, LCP).  PPP CHAP authentication can be used when the
>    SI and SC are on a trusted, non-public IP network.
> 
>    Since CHAP does not provide per-packet authentication, integrity, or
>    replay protection, PPP CHAP authentication MUST NOT be used
>    unprotected on a public IP network.

I think here is a gap in the logic. PPP CHAP and other mechanism
(IPsec) could be co-existent. so there seems to be no reason
to eliminate PPP CHAP.

> 3.4.1.1.1.  L2TPv2 Authentication
> 
>    L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication
>    during the control connection establishment [RFC2661, 5.1.1].  The
>    same restrictions apply to L2TPv2 authentication and PPP CHAP.

ditto.

thanks,

--
Yasuhiro SHIRASAKI @ NTT Communications
t: +81-3-6800-3262, f: +81-3-5365-2990

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: Florent Parent <[email-masked]>
Date: Wed, 21 Mar 2007 14:29:09 +0100

Hello Yasuhiro.

Thanks for taking time to comment the draft. My comments inline.

> desired and recommenced to secure the communication.'

This document does not want to mandate IPsec in *all* cases. We tried to 
identify scenarios where security is required, and what security to apply 
(IPsec). We'll change some text in the introduction to clarify this.

The security analysis in RFC 3193 is quite appropriate for this draft. This 
draft will describe how recommendations from RFC 3193 can be applied using 
the new IPsec security architecture (RFC4301) and IKEv2.

> suppored by the softwire.'

The reason IPsec is not mentioned here is that we haven't yet discussed 
what are the security requirements (defined in 3.4). We're just stating a 
"use case" for softwire.

> (IPsec) could be co-existent. so there seems to be no reason

I agree that we should not eliminate CHAP, and we are not. The key word 
here is "unprotected". If you're L2TP tunnel is protected using IPsec, 
nothing here prohibits using CHAP user authentication.

>>    same restrictions apply to L2TPv2 authentication and PPP CHAP.

Ditto :)

We'll add some text to clarify that L2TPv2 should not be used unprotected, 
as for CHAP. Sounds ok?

Thanks again.
Florent

---

From: Yasuhiro SHIRASAKI <[email-masked]>
Date: Thu, 22 Mar 2007 21:45:09 +0900 (JST)

Hi Florent,

On Wed, 21 Mar 2007 14:29:09 +0100,
> the new IPsec security architecture (RFC4301) and IKEv2.

When I read the draft, I was afraid that IPsec would be mandated.
That's the reason why I sent my comments. I believe the clarification
helps a lot.

> what are the security requirements (defined in 3.4). We're just stating a 

agree.

> nothing here prohibits using CHAP user authentication.

I got your point.

> We'll add some text to clarify that L2TPv2 should not be used unprotected, 

sounds nice.

thanks.