Subject: [v6ops] draft-ietf-v6ops-cpe-simple-security

From: james woodyatt <[email-masked]>
Date: Mon, 27 Sep 2010 17:18:55 -0700

everyone--

Alas, one of the technical comments on this draft related to IPv6 Mobility Support requires further discussion in the working group before we can say we have achieved rough consensus.

Julien Laganier has brought up the point that under certain circumstances with the current recommendations, IPv6 Simple Security will prevent an interior mobile node from establishing bindings with an exterior home agent.  This can happen when the mobile node sends an outbound Mobility Header packet to the home agent, because the IP-in-IPv6 return path from the home agent to the mobile node will not be opened.

I propose inserting recommendations into section 3.2.5 similar to the following:

+ REC-A1: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward, in both directions, the IPv4 and IPv6 packets that are encapsulated in IPv6 associated with tunnel between the home agent and the correspondent node.

+ REC-A2: If a gateway forwards a Mobility Header [RFC3775] flow, then it MUST also forward (in the reverse direction) ICMPv6 "Destination Unreachable" and "Packet Too Big" messages containing any headers that match the associated flow state records.

This would still have the effect of preventing exterior mobile nodes from establishing bindings with interior correspondent nodes by initiating unsolicited inbound flows, which I think is consistent with the basic ambit of IPv6 simple security, while permitting interior mobile nodes to obtain pretty much the same service as any other interior nodes.

Thoughts?  Discussion?  Objections?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Rémi Després <[email-masked]>
Date: Tue, 28 Sep 2010 11:14:15 +0200

> Thoughts?  Discussion?  Objections?

No objection to this addition, and/or to a note explaining the effect of simple security on IPv6 mobility.

IMHO, this is one more reason to prefer that simple-security capable CPEs have the Transparent mode as their default mode (simple-secutity filters disabled).
Vendors should be well aware of known consequences of deliberately breaking the incoming reachability that IPv6 was otherwise restoring.
They must be prepared for customer-support costs when things that should work don't.

Regards,
RD

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops