Subject: Re: [secdir] Secdir review of draft-ietf-mip4-dsmipv4-07

From: Jari Arkko <[email-masked]>
Date: Tue, 04 Nov 2008 15:29:49 +0200

Yaron,

Thanks for your review. I agree with the security comments. I placed the 
following RFC Editor note. Everyone happy? The authors should of course 
take these notes into a new version, if it is needed for other reasons.

> Please add change in Section 4.3: mechanisma -> mechanisms
>
> Please change in Section 6:
> OLD:
> Similar to the procedures specified for Mobile IPv4 [RFC3344] number
> spaces, future allocations from this number space require expert
> review [RFC5226].
> NEW:
> Similar to the procedures specified for Mobile IPv4 [RFC3344] number
> spaces, future allocations from the two new number spaces require
> expert review [RFC5226].
>
> Please add a paragraph to the end of Section 5:
>
> Interactions with Mobile IPv4 and IPsec have been covered elsewhere,
> for instance in [RFC5265] and [RFC5266].
>
> Please add two informative references for RFC5265 and RC5266.

Jari

Yaron Sheffer wrote:
>
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG. These comments were written primarily for the benefit of the 
> security area directors. Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> I found this document very well written. I did not find additional 
> security issues beyond those documented in the Security 
> Considerations, other than the establishment of yet another tunneling 
> method. Such methods are often abused in order to bypass security 
> middleboxes. However it does make sense to discuss interactions with 
> the existing documents on MIP4 and MIP6 security, see below.
>
> Security comments:
>

> - There are two recent RFCs on the interaction between Mobile IP and 
> IPsec, RFC 5265 and 5266. I would expect the current document to refer 
> to the interaction between IPsec and DSMIP. IPsec for this traffic 
> will be affected by two factors: (1) protecting MIP4 traffic does not 
> protect *all* traffic, in the case of tunneling to the CoA, and (2) as 
> always with nested tunnels, access control policy will not be enforced 
> correctly, because only the IP-in-IP header will be used to authorize 
> the traffic.
>
> - This document establishes TWO new ways to tunnel IPv6 traffic, one 
> inside of MIP4 tunneling and another “in parallel” to MIP4 traffic. 
> Security devices will have to learn how to detect and secure this 
> traffic. I would expect an informative reference to 
> draft-ietf-v6ops-tunnel-security-concerns.
>
> Other comments:
>
> - IMHO, the document would be easier to read through if Sec. 3 
> (formats) were moved *after* Sec. 4 (processing rules).
>
> - In the IANA considerations, it is unclear if the last paragraph 
> (expert review) refers to the preceding paragraph, or to both of the 
> new number spaces.
>
> - 4.3: spelling: mechanisma -> mechanisms
>

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

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 05 Nov 2008 00:37:09 +1100

Looks good to me. Thanks Jari and Yaron for the reivew.

Hesham

On 5/11/08 12:29 AM, "Jari Arkko" <[email-masked]> wrote:

>> inside of MIP4 tunneling and another ³in parallel² to MIP4 traffic.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 4 Nov 2008 17:00:12 +0200

Hi Jari,

I'm not sure I'm happy... As far as I understand this protocol, it includes
a facility (tunneling to CoA) of using MIP4 signaling (presumably protected
by IPsec/MOBIKE) to establish a completely separate, out of band and
unprotected, IPv6 flow. This is a completely new animal, and that seems to
make the proposed resolution (just add a reference to RFC 5265 and 5266)
insufficient. In fact, these two RFCs may need to be extended to cover this
new option.

Is there anything major that I'm missing?

Thanks,
	Yaron

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2008 15:30
To: Yaron Sheffer
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Henrik Levkowetz;
[email-masked]
Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07

Yaron,

Jari

> inside of MIP4 tunneling and another "in parallel" to MIP4 traffic.

Scanned by Check Point Total Security Gateway.
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 4 Nov 2008 18:40:45 +0200

Hi George,

Thanks for the clarification. Yes, this does make sense.

The whole thing makes access control within the IPsec tunnel (the SPD) sort
of useless in these scenarios. But this milk was already spilled in RFC
5265.

Best,
	Yaron

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Tuesday, November 04, 2008 18:19
To: Yaron Sheffer
Cc: Jari Arkko; [email-masked]; [email-masked]; [email-masked];
[email-masked]; Henrik Levkowetz; [email-masked]
Subject: Re: Secdir review of draft-ietf-mip4-dsmipv4-07

Hi Yaron,

MIPv4 sets up a tunnel between the HA and the MN's CoA. Over this
tunnel the HA forwards IPv4 traffic between the corresponding nodes
(CNs) IP Address and the MN's home address (HoA).

DS-MIPv4 extends MIPv4 so that in addition to IPv4 traffic the HA can
forward IPv6 traffic over the same HA-CoA tunnel.

So, when the HA forwards packets to the MN it uses one of the following:
Packets with destination address the MN's IPv4 HoA are forwarded over
the HA-CoA tunnel
Packets with destination address the MN's IPv6 (home registered
prefixes) are also forwarded over the HA-CoA tunnel.

The specification also allows for a double encapsulation. This results to:
Packets with destination address the MN's IPv6 (home registered
prefixes) are forwarded to a tunnel between the HA's IPv4 address and
MN's IPv4 HoA, which are then forwarded over the HA-CoA tunnel.

In that sense DSMIPv4 always tunnels packets to the MN's CoA (as
RFC3344 MIPv4) either directly or via the use of double encapsulation
(i.e., it never creates a "parallel tunnel". So, the IPSEC
interactions described in RFC5265/5266 should apply here too.

The only thing we should possibly add is that security devices should
look for this potential double encapsulation over which IPv6 traffic
is some times sent.

Would that make sense?

George

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 4 Nov 2008 14:30:16 +0000

Yes, these look ok to me. Yaron thanks for your review.
George

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 4 Nov 2008 16:19:21 +0000

Hi Yaron,

Would that make sense?

George

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 4 Nov 2008 16:52:37 +0000

OK, good. I will make this clearer in the draft as I incorporate the
suggestions from Jari.

Thanks again.
George