Re: WGLC: draft-ietf-v6ops-cpe-simple-security-10.txt

[Fred Baker <fred@cisco.com>]

Thanks. On your first point, we tossed around the idea of merging it into draft-ietf-cpe-router and chose not to. This document describes an additional feature that vendors MAY build into a CPE Router.

On Apr 20, 2010, at 9:17 AM, Laganier, Julien wrote:

>> Fred Baker wrote: 
>> 
>> As agreed at the last IETF meeting, I am opening a two week WGLC of 
>> draft-ietf-v6ops-cpe-simple-security-10.txt. Please read the document, 
>> comment to this list on matters of substance, and send nits (spelling/
>> grammar, word choice, sentence structure comments) to the authors.
> 
> I realize I am late with this but I have reviewed the document and have the following comment:
> 
> The document does not explicitly mention how should IPv6 be treated by a CPE. 
> 
> Mobile IPv6 involves the use of IP-in-IP tunneling and of IPsec and IKE, all of which seems to be covered in Section 2.2. in an adequate manner:
> 
> 2.2.  Internet Layer Protocols
> 
>   As virtual private networking tunnels are regarded as an unacceptably
>   wide attack surface, this document recommends the DEFAULT operating
>   mode for residential IPv6 simple security is to treat IP-in-IP and
>   GRE tunneling protocols as opaque transport layers, i.e. inbound
>   tunnel initiations are denied and outbound tunnel initiations are
>   accepted.  IPsec transport and tunnel modes are explicitly secured by
>   definition, so this document recommends the DEFAULT operating mode
>   permit IPsec and Internet Key Exchange (IKE) flows to pass without
>   filtering.
> 
> Mobile IPv6 also involves the use of the Mobility Header, which seems to be appropriately covered by the recommendation of Section 3.2.2.:
> 
> 3.2.2.  Upper-layer Transport Protocols
> 
>   Residential IPv6 gateways are not expected to prohibit the use of
>   applications to be developed using future upper-layer transport
>   protocols.  In particular, transport protocols not otherwise
>   discussed in subsequent sections of this document are expected to be
>   treated consistently, i.e. as having connection-free semantics and no
>   special requirements to inspect the transport headers.
> 
>   In general, upper-layer transport filter state records are expected
>   to be created when an interior endpoint sends a packet to an exterior
>   address.  The filter allocates (or reuses) a record for the duration
>   of communications, with an idle timer to delete the state record when
>   no further communications are detected.
> 
>   REC-10: Filter state records for generic upper-layer transport
>   protocols MUST BE indexable by a 3-tuple comprising the interior node
>   address, the exterior node address and the upper-layer transport
>   protocol identifier.
> 
>   REC-11: Filter state records for generic upper-layer transport
>   protocols MUST NOT be deleted or recycled until an idle timer not
>   less than two minutes has expired without having forwarded a packet
>   matching the state in some configurable amount of time.  By DEFAULT,
>   the idle timer for such state records is five minutes.
> 
> However MIPv6 also relies on the use of a degenerated tunneling mechanism between a Mobile Node and its corresponds nodes. This tunneling involves the use of the Routing Header Type 2 and of the Home Address destination option, which are not covered in the document. 
> 
> In practice I believe this type of tunnel should be treated as IP-in-IP tunnels, but this is currently not the case. The issues is as follows:
> 
> Outbound packets sent in the tunnel are sent from the Mobile Node Care-of Address and with a Home Address destination option -- so it seems that there is no problem for those, although we might want to be explicit.
> 
> However inbound packets corresponding to an outbound initiated tunnel should be accepted as well (as for IP-in-IP), but these packets will be destined to the Home Address and carrying the Care-of Address in the Routing Header Type 2, so they will not be handled properly absent an explicit recommendation that the CPE tracks MIPv6 HoA/RH2 degenerated tunnels.
> 
> I believe we should cover MIPv6 adequately in this specification by adding explicit tracking of outbound initiated MIPv6 HoA/RH2 degenerated tunnels. 
> 
> [ The MEXT WG has two documents specifying firewall behavior for MIPv6 that could be used as a starting point for text to be included in this spec -- see http://tools.ietf.org/html/draft-ietf-mext-firewall-vendor-02 and http://tools.ietf.org/html/draft-ietf-mext-firewall-admin-02 ]
> 
> What do people think?
> 
> --julien
> 
> 
> 

http://www.ipinc.net/IPv4.GIF