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