Subject: Re: [v6ops] 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

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 13 Sep 2010 13:50:46 -0700

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: [email-masked] [mailto:ietf-announce-
> [email-masked]] On Behalf Of The IESG
> Sent: Monday, September 13, 2010 8:14 AM
> To: IETF-Announce
> Cc: [email-masked]
> 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
> [email-masked] mailing lists by 2010-09-27. Exceptionally, comments may
> be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Sep 2010 09:47:53 +0200

Hi,

I have one small follow up on this message. I had one nagging feeling
about an potential issue, but as I wasn't sure I didn't included this
until I got some confirmation that it was potentially an issue. I
primarily want to know if you have considered the following issue:

As IPsec traffic is let through the CPE without any filtering. Normal
IPsec will require established security associations to allow the
traffic up. However, we do have the BTNS work (RFC 5386) that would
allow for "anonymous" creation of security associations. This seems to
be a potential for a case where unwanted and unsolicited traffic can be
injected into a host behind the CPE.

It is not like there aren't other methods to get it in, simply that this
is a chink in the armor one might not consider. Maybe a warning about
this in the document?

Cheers

Magnus

Magnus Westerlund skrev 2010-09-24 16:28:
> I've reviewed this document as part of the transport area directorate's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's authors for their information and to allow them to address
> any issues raised. The authors should consider this review together with
> any other last-call comments they receive. Please always CC
> [email-masked] if you reply to or forward this review.
> 
> I found no significant issue in my review. In all these timer cases it
> uses the agreed on behave values as far as I remembers. The document
> appears ready for publication.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------