Subject: RE: [mobile-ip] Question on draft-team-mobileip-mipv6-sec-reqts-00.txt

From: [email-masked]
Date: Tue, 17 Jul 2001 13:25:48 -0500

Hello,

> Hi,
> 
> I'm no security expert and I have this humble question.
> 
> The requirements presented are so directly related to cryptography.
> The word "authorized" is used extensively.  I was wondering if it is
> possible to include requirements that are more "functional" in nature
> and that would allow solutions that do not rely necessarily on crypto.
>

It would be interesting to see solutions that do not rely on any crypto
to solve the MIPv6 security problem.
 
> For example, the wireless broadcast would allow the MN to overhear
> when a BU with its Home Address were sent by an attacker.
> 

True. But is a legitimate MN even monitoring for such data on the
wireless
links? Probably not. And an attacker does not have to send a BU (with
the MNs home address) over the wireless link. 

The document aims to capture various scenarios and threat models and
this
is one possibility.

> Another example is that the AR's usually trust each other and thus
> might easily exclude an unauthorized AR.
> 

I am not sure I get the point here. Are you refering to a specific
scenario in 
the document when you make this observation?

> Just wondering,
> Alex

-Basavaraj

---

From: Alexandru Petrescu <[email-masked]>
Date: 18 Jul 2001 10:58:49 +0200

> to solve the MIPv6 security problem.

My remark was not to say that I have such solution in mind.  I was
mainly pointing out to solve only the minimal set of needs by using
crypto.

> wireless links? Probably not.

Why wouldn't a legitimate MN monitor the wireless link?

> scenario in the document when you make this observation?

YEs, I was referring to threat B.3 but with a twist.  If attacker adds
new AR by attaching to the same point where the other AR's are
attached (and not by DR'ing to an existing AR as in threat B.3) then
it should be the trust relationships between existing AR's that will
exclude the attacker AR.

The threat of attaching an AR as described above could probably be
added as Threat B.4.

Alex