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