From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
Date: August 24, 2008 4:15:53 AM PDT
To: jhw@apple.com, v6ops-residential-cpe-design-
team@external.cisco.com
Subject: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03
Hi,
I've finally found a bit of time to start having a read through the 03
version of this draft. I haven't read through all of it yet, however
here are some starting suggestions:
2. Overview
Change "requires" to "provides", just to continue to emphasise a bit
that the statefulness of NAT wasn't specifically designed into it:
"Only the perceived security benefits associated with stateful packet
filtering, which NAT (requires|*provides*) as a side effect, are
thought relevant in the IPv6 residential usage scenario."
2.2. Internet Layer Protocols
"Therefore, this document recommends the DEFAULT operating mode for
residential IPv6 simple security is to permit all virtual private
networking tunnel protocols to pass through the stateful filtering
function. These include IPsec transport and tunnel modes as well as
other IP-in-IP protocols."
Would it be better to restrict this to authenticated tunnelling
protocols? Wrapping a malicious packet inside a GRE or IP packet and
having the CPE blindly forward it would seem to me to be a really
simple and easy way to bypass all the security mechanisms that this
draft is defining.
Authenticated protocols could still expose hosts to probing e.g.
probing a non-IPsec enabled host via IKE, which the CPE would
forward unrestricted, could generate an ICMPv6 Port Unreachable,
indicating a host's presence. Maybe the residential CPE should drop
these ICMPv6 messages in the outbound direction, hiding hosts that
don't
support the tunnelling method being requested from these sorts of
probes?
A few thoughts related to general tunnel security. Is it appropriate
for
this draft to document that traffic arriving encapsulated should not
automatically be trusted, and therefore should also have firewalling
applied to it by the receiving host, after decapsulation? If the end
user has chosen to use a clear text tunnel encapsulation method e.g.
GRE, would there be any value in specifying that the CPE MAY inspect
the
interior traffic carried within the tunnel? Limiting the number of
encapsulation headers on a packet would also probably be something to
define in this case. IOW, if the CPE can inspect traffic, even though
it is encapsulated inside a tunnel, can we recommend that it should?
"R2: Packets bearing in their outer IPv6 headers multicast destination
addresses of equal or narrower scope that the configured scope
boundary level of the gateway MUST NOT be forwarded in any
direction."
suggest to insert:
", excepting when the Residential Gateway is also acting as a VPN
tunnel end-point. In this case, traffic must not be forwarded toward
multicast destinations that are not known to be at the remote end of
the pre-established or prior-configured on-demand tunnel(s)."
"R4: Outbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header does not have a unicast prefix assigned for
use by globally reachable nodes on the interior network."
similar to above, suggest to insert:
", excepting when the Residential Gateway is also acting as a VPN
tunnel end-point. In this case, traffic must not be forwarded to
unicast destinations that are not known to be at the remote end of the
pre-established or prior-configured on-demand tunnel(s)."
"R4: Inbound packets MUST NOT be forwarded if the source address in
their outer IPv6 header has a global unicast prefix assigned for
use
by globally reachable nodes on the interior network."
suggest to add tunnel end-point text as per above.
"R5: Packets MAY be discarded if the source and/or destination address
in the outer IPv6 header is a unique local address. By DEFAULT,
gateways SHOULD NOT forward packets across unique local address
scope boundaries."
suggest to add tunnel end-point text as per above.
That's it for the moment, I'll continue reading through it over the
next few days.
Regards,
Mark.