Fwd: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03

[Fred Baker <[e-mail]>]

Forwarding comments...

Begin forwarded message:

> From: Mark Smith <[e-mail]>
> Date: August 24, 2008 4:15:53 AM PDT
> To: [e-mail], v6ops-residential-cpe-design- 
> [e-mail]
> 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.