Review of draft-ietf-v6ops-cpe-simple-security-12

[arno@natisbad.org (Arnaud Ebalard)]

Hi,

I read the draft (except for SCTP and DCCP related parts). IMHO, it is
in good shape. I have some comments inline below. They are mainly
related to IPsec/IKE and MIPv6.

Please, bear with me if some have already been discussed on the list; I
have not followed associated discussions.


> 2.  Overview
> 
>    For the purposes of this document, residential Internet gateways are
>    assumed to be fairly simple devices with a limited subset of the full
>    range of possible features.  They function as default routers
>    [RFC4294] for a single local-area network, e.g. an Ethernet, a Wi-Fi
>    network, a bridge between two or more such segments.  They have only
>    one interface by which they can access the Internet service at any
>    one time, using any of several possible sub-IP mechanisms including
>    tunnels and transition mechanisms.
> 
>    In referring to the security capabilities of residential gateways, it
>    is reasonable to distinguish between their "interior" network, i.e.
>    the local-area network, and their "exterior" networks, e.g. the
>    public Internet and the networks of Internet service providers.  This
>    document is concerned only with the behavior of IP packet filters
>    that police the flow of traffic between the interior IPv6 network and
>    the exterior IPv6 networks of residential Internet gateways.
> 
>    The operational goals of security capabilities in Internet gateways
>    are described with more detail in "Local Network Protection for IPv6"
>    [RFC4864], but they can be summarized as follows.
> 
>    o  Check all traffic to and from the public Internet for basic
>       sanity, e.g. anti-spoofing and "martian" [RFC4949] filters.
> 
>    o  Allow tracking of applications usage by source and destination
>       transport addresses.

       s/transport/network/  ?


> 3.1.  Stateless Filters
> 
>    [snip]
> 
>    REC-8: By DEFAULT, inbound non-recursive DNS queries received on

                                ^^^^^^^^^^^^^
Why non-recursive? What about recursive ones? In the end, is the
integrated DNS resolver expected to process any kind of DNS solicitation
originating from outside?

>    exterior interfaces MUST NOT be processed by any integrated DNS
>    resolving server.
> 
>    REC-9: Inbound DHCPv6 discovery packets [RFC3315] received on
>    exterior interfaces MUST NOT be processed by any integrated DHCPv6
>    server.
> 
> 3.2.  Connection-free Filters
> 
>    Some Internet applications use connection-free transport protocols
>    with no release semantics, e.g.  UDP.  These protocols pose a special
>    difficulty for stateful packet filters because most of the
>    application state is not carried at the transport level.  State
>    records are created when communication is initiated and abandoned
>    when no further communication is detected after some period of time.
> 
> 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. 

Maybe the weird behavior of existing boxes made me paranoid.


> 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.

Cheers,

a+