[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Review of draft-ietf-v6ops-cpe-simple-security-12
Hi Arnaud & James,
I have a follow-up comment inline below:
> Hi,
>
> I read the draft (except for SCTP and DCCP related parts). IMHO, it is
> in good shape. I have some comments inline below. They are mainly
> related to IPsec/IKE and MIPv6.
>
> Please, bear with me if some have already been discussed on the list; I
> have not followed associated discussions.
[...]
> > 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.
> > 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.
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.
> 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.
As a result, and in a similar fashion to what Arnaud wrote just 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.
--julien