RE: Last Call: <draft-ietf-v6ops-cpe-simple-security-12.txt> (Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service) to Informational RFC

["Laganier, Julien" <[e-mail]>]

Arnaud Ebalard and myself made substantial comments to the v6ops WG that have not been addressed yet because WGLC had concluded and publication was requested. I still believe these should be addressed before publication. I am copying the comments that we made below:

Arnaud's comments:
------------------

> 3.2.1.  Internet Control and Management
> 
>    Recommendations for filtering ICMPv6 messages in firewall devices are
>    described separately in [RFC4890] and apply to residential gateways
>    with the additional recommendation that incoming "Destination
>    Unreachable" and "Packet Too Big" error messages that don't match any
>    filtering state should be dropped.
> 
>    REC-10: IPv6 gateways SHOULD NOT forward ICMPv6 "Destination
>    Unreachable" and "Packet Too Big messages" containing IP headers that
>    do not match generic upper-layer transport state 3-tuples.

I understand the purpose of the REC but I wanted to point the following
just in case: if one decides to hardcode one of the other requirements
without internally creating an "upper-layer transport state 3-tuples"
(e.g. treat it statelessly), the result will be that associated ICMPv6
traffic may be dropped.

The example I can provide is associated with the default pass-through
rule for ESP (REC-21) which contain a MUST but REC-23 contains only a
SHOULD for the use of a filter state record. I would like to avoid
ESP-related traffic (e.g. PMTUD traffic) to get dropped.

ESP does not seem to have the same kind of clarification than the one
that REC-17 provides for UDP or REC-31 provides for TCP, i.e. something
like "If a gateway forwards a ESP traffic flow, it MUST also forward
ICMPv6 "Destination Unreachable" and "Packet Too Big" messages
containing ESP headers that match the flow state record." Another
solution would be to add a warning about related traffic in REC-21 or
REC-23.

> 3.2.4.  IPsec and Internet Key Exchange (IKE)
> 
>    The Internet protocol security suite (IPsec) offers greater
>    flexibility and better overall security than the simple security of
>    stateful packet filtering at network perimeters.  Therefore,
>    residential IPv6 gateways need not prohibit IPsec traffic flows.
> 
>    REC-20: In their DEFAULT operating mode, IPv6 gateways MUST NOT
>    prohibit the forwarding of packets, to and from legitimate node
>    addresses, with destination extension headers of type "Authenticated
>    Header (AH)" [RFC4302] in their outer IP extension header chain.
> 
>    REC-21: In their DEFAULT operating mode, IPv6 gateways MUST NOT
>    prohibit the forwarding of packets, to and from legitimate node
>    addresses, with an upper layer protocol of type "Encapsulating
>    Security Payload (ESP)" [RFC4303] in their outer IP extension header
>    chain.
> 
>    Internet Key Exchange (IKE) is a secure mechanism for exchanging
>    cryptographic material. Residential IPv6 gateways are expected to
>    facilitate the use of IPsec security policies by allowing inbound IKE
>    flows.

What about the following to replace the first sentence:

     Internet Key Exchange (IKE) is a secure mechanism for performing
     mutual authentication, exchanging cryptographic material and
     establishing IPsec Security Associations between peers.

> 3.2.5.  Mobility Support in IPv6
> 
>    Mobility support in IPv6 [RFC3775] relies on the use of an
>    encapsulation mechanism in flows between mobile nodes and their
>    correspondent nodes, involving the use of the type 2 IPv6 routing
>    header and the Home Address destination header option.  

It also relies on Mobility Header (nh 135) passing through, for
instance for required CoTI/CoT messages exchanged between the MN and the
CN, before traffic using HAO in DestOpt or RH2 is exchanged. IMHO, there
should be a REC to support MH to pass through. Even inbound MH traffic:
more on that below.

>                                                          In contrast
>    to mobility support in IPv4, mobility is a standard feature of IPv6,
>    and no security benefit is generally to be gained by denying
>    communications with either interior or exterior mobile nodes.
> 
>    REC-25: The state records for flows initiated by outbound packets
>    that bear a Home Address destination option [RFC3775] are
>    distinguished by the addition of the home address of the flow as well
>    as the interior Care-of address.  IPv6 gateways MUST NOT prohibit the
>    forwarding of any inbound packets bearing type 2 routing headers,
>    which otherwise match a flow state record, and where A) the
>    destination matches the home address of the flow, and B) the Home
>    Address field in the routing header matches the interior Care-of
>    address of the flow.

I think the last sentence is wrong. It should IMHO be:

     IPv6 gateways MUST NOT prohibit the forwarding of any inbound
     packets bearing type 2 routing headers, which otherwise match a
     flow state record, and where A) the address in the destination
     field of the IPv6 header matches the interior Care-of Address of
     the flow, and B) the Home Address field in the Type 2 Routing
     Header matches the Home Address of the flow.

In more details, when a RO packet (e.g. TCP, MH, UDP, ...) is received
by an internal MN from an external CN, its on-wire format is the
following:

  IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP

This is what the CPE will see.

Additionally, this REC-25 supports an internal MN exchanging RO traffic
with an external CN:

   MN --------- CPE ----------------- Internet -------------- CN

    ---- IPv6(src=CoA, dst=CN)/DestOpt(HOA(hoa=HoA))/TCP ---->
    <--- IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP -------

*but does not* support an internal CN (or MN) accepting bindings for an
external MN, i.e.:


   CN --------- CPE ----------------- Internet -------------- MN (CoA, HoA)

    <--- IPv6(src=CoA, dst=CN)/DestOpt(HOA(hoa=HoA))/TCP -----
    ---- IPv6(src=CN,dst=CoA)/RH2(HomeAddress=HoA)/TCP ------>

is that out of scope or is it just missing? If that is not out of scope,
a specific REC may be needed or REC-25 may be extended. Additionally,
for that to be useful, inbound MH traffic need to be authorized.

There is also another unrelated point associated with this REC-25: using
TCP as an example, the CPE may not see the 3-way handshake between a MN
and a CN if the TCP connection establishment is done via the tunnel to
the Home Agent. Later, when this TCP traffic is route optimized, no TCP
state exist in the CPE. I understand that REC-25 covers that with the
"any" keyword in "IPv6 gateways MUST NOT prohibit the forwarding of
*any* inbound packets bearing type 2 routing headers, ..." but I don't
think it will be obvious for someone not familiar with the protocol that
standard TCP RECs do not apply here, i.e. that somehow REC-25 applies
before stateful rules. Stating it explictly in the document may help.

My follow up comments:
----------------------

Irrespective of whether bidirectional tunneling through the Home Agent or route optimization is used, there is an additional issue with a mobile node moving from a network behind a first CPE to another network behind a second CPE: If the upper layer protocol (e.g., TCP) state is established when the MN is behind a first CPE, if later on the MN moves behind a second CPE, the second CPE will not have any state for the upper layer protocol. 

As a result, and in a similar fashion to what Arnaud wrote above, I believe all traffic to and from the mobile node should be passed through the CPE, whether it is encapsulated with IP-in-IP in the case of bidirectional tunneling through the Home Agent or with HAO/RH2 in the case of Route Optimized traffic.

Note that none of this traffic will be processed by the Mobile Node unless the Mobile Node has a will to decapsulate inner packets. Mobile IPv6 mandates that the MN processes no inbound encapsulated packets unless it has a binding cache entry with the correspondent. Thus I believe this is fine from a security perspective.

--julien


> -----Original Message-----
> From: [e-mail] [mailto:ietf-announce-
> [e-mail]] On Behalf Of The IESG
> Sent: Monday, September 13, 2010 8:14 AM
> To: IETF-Announce
> Cc: [e-mail]
> Subject: Last Call: <draft-ietf-v6ops-cpe-simple-security-12.txt>
> (Recommended Simple Security Capabilities in Customer Premises
> Equipment for Providing Residential IPv6 Internet Service) to
> Informational RFC
> 
> 
> The IESG has received a request from the IPv6 Operations WG (v6ops) to
> consider the following document:
> - 'Recommended Simple Security Capabilities in Customer Premises
>    Equipment for Providing Residential IPv6 Internet Service'
>   <draft-ietf-v6ops-cpe-simple-security-12.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2010-09-27. Exceptionally, comments may
> be sent to [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-simple-security/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-simple-security/
> 
> 
> No IPR declarations were found that appear related to this I-D.
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce