[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 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