Subject: Re: [Softwires] WG LC Problem Statement (Francis Dupont, non-editorial)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 9 Jan 2006 21:45:45 -0600

Just working through the comments...

Thanks,

Spencer

> In your previous mail you wrote:
>
>       We are staring the WG last call on the problem statement draft:
>
> => I noted many things last week, here are the not-editorial comments
> (please note I haven't yet read the other comments):
>
>
> Network Working Group                                              X. Li
> Internet-Draft                                                    CERNET
> Expires: June 10, 2006                                         A. Durand
>                                                                 Comcast
>                                                             S. Miyakawa
>                                                      NTT Communications
>                                                                J. Palet
>                                                             Consulintel
>                                                               F. Parent
>                                                                  Hexago
>                                                                 D. Ward
>                                                           Cisco Systems
>                                                        December 7, 2005
>
>
> => there are too many authors (the limit is 5), I suggest to apply
> http://www.rfc-editor.org/policy.html "Author Overload"

This is actually more complicated than I thought it would be :-) but we'll 
do the right thing.

>
> 1.  Requirements Notation
>
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in [RFC2119].
>
> => IMHO it is not a good idea to use the requirement keywords in a
> problem statement document. BTW they are not use in a coherent way
> in this document.

Alain/David, can you make a call on RFC 2119 language in this draft? 
Practice varies between working groups - Francis is correct that it needs to 
be used consistently (whether I am consistently adding it or taking it 
away).

> 3.  Hubs and Spokes Problem
>
> => as the CPE is the central concept it should be really fine to
> explain where is this #@$ CPE in these 3 cases.

We were using CPE and HGW interchangeably. I have changed the document to 
use HGW in all cases.

> 3.3.  Non upgradable CPE router
>
> => please explain this is related to cases 2 and 3, but not 1.

Nice catch. I added "which is dual-stack", so the description of case 1 is 
now

Softwire initiator is the HGW, which is dual-stack,

and "(as shown in Case 2 and Case 3)"

to

<t>When the HGW router cannot run in dual stack mode (as shown in Case 2 and 
Case 3)

> 3.4.  Static Prefix Delegation
>
> => delegation is not assignment, i.e., take care to use the right term.
>

OK.

> 3.7.  Softwire Concentrator Discovery
>
> => the term "hostname" (in place of simply "name") closes the door to
> smarter scheme like RFC2782, i.e., SRV vs. A RRs.
>

Now using "name".

> 3.11.1.  Authentication, Authorization and Accounting
>
>   The softwire protocol must support user authentication in order to
>   authorize access to the service, and provide adequate logging of
>   activity (accounting).
>
> => I strongly object against the word "user" here: this limit the
> scenarios to mono-user when multi-user boxes and systems can become
> again the common case. We need a better word, as we have CPE every two
> lines I propose "customer".

OK.

>
> 4.1.  Mesh Description
>
> => IMHO it is not clear in the document whether the case of private
> IPv4 networks spread on many islands is supported...

I see what you mean. I made a change a little further down - text now reads:

 <section title="Encapsulations">

<t>IPv6-in-IPv4, IPv4-in-IPv6 and overlapping address space as defined in 
the L3VPN
working group (including overlapping RFC-1918 private address space)
are on the critical path for "Mesh" softwires.

>
> 4.6.  Security
>
>   In contrast with the hub and spoke problem, routers are advertizing
>   routers for relatively large islands, and never a single user so
>   there is no "user authentication" necessary.  However, if running
>   over an untrusted network, control or data plane security may be
>   necessary.
>
> => s/user/customer/

I'm not so sure about this one (if I'm providing ISP service to Renault, I 
might want to authenticate my CUSTOMER, just not individual users who work 
for Renault - so saying "no customer authentication" seems wrong). Make 
sense? How about

 <t>In contrast with the hubs and spokes problem, routers are advertizing 
routers
 for relatively large network islands, not individual users, so fine-grained 
authentication
 is not necessary.
 However, if running over
 an untrusted network, control or data plane security may be necessary.</t>

(I don't want to exclude BGP "authentication" in the future, right?)

> 6.  Security Considerations
>
>   The softwire protocol (control plane) must support user
>
> => s/user/customer/
>
>   authentication, and should be configurable to offer mutual
>   authentication.  The authentication mechanism has to be compatible
>   with existing AAA protocols.  The authentication must be protected
>   using an already defined secure mechanism.
>
> => note the sections 4.6 and 6 need to say compatible things (:-).

Nice catch! Actually ... I need to point section 6 to the "Hubs and Spokes" 
and "Mesh" Security sections, instead of having all three independently, I 
think...

How about changing Section 6 to

<t>Security considerations specific to the "Hubs and Spokes" and "Mesh"
models appear in those sections of the document.</t>

<t>As with any tunneling protocol, using this protocol may introduce a
security issue by circumventing a site security policy implemented as
ingress filtering.</t> 

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