Subject: RE: [Mip6] Security Considerations section ofdraft-ietf-mip6-nemo-v4traversal-00.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 25 Oct 2005 14:59:10 -0400

> > => No that's not possible. The HA knows the IPv4 address 
 > > corresponding to the MN's IPv6 HoA. Just like it would 
 > know the home 
 > > prefix corresponding to the IPv6 HoA of the MR.
 > 
 > How does it know it?  The NEMOv6 spec has a Prefix Table for 
 > that, and
 > the NEMOv4 personal draft too.  This draft does not have 
 > such a table.

=> A "Table" is an implementation specific issue. I agree that
it should be explicitly stated in the draft. We can add that.
But FWIW that is the assumption in the draft today. We can
explicitly add that in the next one. 

 > 
 > > Therefore, in order to authorize the mobile node's IPv4 
 > home address 
 > > binding, the home agent MUST store the IPv4 address 
 > corresponding to 
 > > the IPv6 address that is allocated to a mobile node.
 > 
 > Do you think this text is sufficient?  Don't you think that 
 > using IPv4
 > IPsec makes more sense?

=> There is no such thing as "IPv4 IPsec". Yes I do think it's
sufficient.

 > > => Of course, but that attack is known for all NAT 
 > detection schemes
 > >  including IKE-based schemes. There is no free lunch with NATs. If 
 > > people deploy them, they suffer the consequences.
 > 
 > That's rhetoric, right?  Too easy to claim weaknesses in 
 > some protocol
 > are due to another protocol.

=> Huh? I didn't claim that. I said that this is a common problem.
A NAT is a MITM. NAT detection is about detecting a MITM. Of course,
that MITM could be a NAT or an attacker. But no one has a way of knowing
that today. So my point is, NATs are bad and we can't get something out of
nothing.

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Oct 2005 21:20:05 +0200

Soliman, Hesham wrote:
>> How does it know it?  The NEMOv6 spec has a Prefix Table for that, 
>> and the NEMOv4 personal draft too.  This draft does not have such a
>> table.
> 
> => A "Table" is an implementation specific issue.

So isn't this targetting the implementors?

> I agree that it should be explicitly stated in the draft. We can add 
> that. But FWIW that is the assumption in the draft today. We can 

Yes, I agree.

>>> Therefore, in order to authorize the mobile node's IPv4 home 
>>> address binding, the home agent MUST store the IPv4 address
>> corresponding to
>> Do you think this text is sufficient?  Don't you think that using 
>> IPv4 IPsec makes more sense?
> 

Ok, I don't.  IPv4 IPsec is IPsec for IPv4.

>>> => Of course, but that attack is known for all NAT detection 
>>> schemes including IKE-based schemes. There is no free lunch with 
>>> NATs. If people deploy them, they suffer the consequences.
>> 
>> That's rhetoric, right?  Too easy to claim weaknesses in some 
>> protocol are due to another protocol.
> 
> => Huh? I didn't claim that. I said that this is a common problem. A 
> NAT is a MITM.

Well, most deployed NATs won't attack anyone, while most MiTMs will.

> NAT detection is about detecting a MITM. Of course, that MITM could
> be a NAT or an attacker.

There should be some mechanisms of distinguishing a temporary MiTM from
a NAT being there for years with same IPv4 public address.

Additionally, the simple mechanism of comparing v4 addresses in the
packet received by HA could be enhanced to mitigate the attack I've
described.  It is sufficient for the MN receiving the fake "NAT Detected
Option" to re-interrogate the HA about that.  This is more secure.

> But no one has a way of knowing that today.

I'm not suggesting to invent something nobody did.  Just to say that the
mechanism proposed in the draft is obviously insecure.  If enhancements
are not proposed then the threats should be acknowledged though.

> So my point is, NATs are bad and we can't get something out of
> nothing.

I somehow agree.

Alex