Subject: [mobile-ip] Security requirements comments

From: Michael Thomas <[email-masked]>
Date: Mon, 8 Oct 2001 17:07:41 -0700 (PDT)

1) On page 10, I don't know what the DR acronym means.

2) B.3: While I agree that MN's should authenticate the AP's,
   I'm not sure that this is in the scope of this WG.
   It seems more like an L2 or URP like problem. Since this
   is requirements document for MIP WG, I don't think we 
   should be making requirements we can't address

3) I didn't see any specific discussion of replay attacks,
   especially from somebody on the same link as either
   MN or CN. It's probably worth a mention, especially
   since the requirements here may not be entirely 
   clear since there isn't an assumption of strong
   authentication

4) Editorial nit: it would be nice to tie the threats
   to the section they were found. It's somewhat
   aesthetically jarring to see sections 6.1 followed
   by A.1 when they are seemingly correlated to the
   section number. Feel free to tell me that it's just
   me :-)

5) In section 6.7, you bring up home agent functionality
   in remote networks (FMIP, HMIP, etc). It's not clear
   to me whether strong or weak authentication should be
   required, nor does this document weigh in on the matter.
   We haven't discussed that on the list yet, and I think
   the requirement should make it explicit which variety
   is acceptible. My inclination is that strong authentication
   should be a MUST.

6) General requirement 4: nit it's cipher. More generally,
   this should be predicated with an "if". That is, "if
   cryptographic mechanisms are utilized in the solution,
   it SHOULD provide a means on using different algorithms."

7) General requirement 5: this is too fuzzy. It should be
   "selectors as defined by RFC 2401"

8) General requirement 8: this is Motherhood and Apple
   Pie, but a little lacking on the "how do I know if I
   met the requirement". I would suggest just dropping
   it since I don't think there's any risk that this
   will not be scrutinized :-)

9) General requirement 10: I would actually like to have
   the requirement that the solution MUST have a means
   of being done without the use of asymmetric crypto.
   As I've posted before, I think that MIPv6 would be
   better served by doing something simple first and
   then layering the optimizations (HA proxy, DH
   exchanges to shorten subsequent exchanges) till a
   later time (ie different RFC).

	      Mike

---

From: [email-masked]
Date: Tue, 09 Oct 2001 14:32:44 +0200 (MEST)

> 1) On page 10, I don't know what the DR acronym means.

Default Route?

>    should be making requirements we can't address

I agree with this, except when AR in visited net has HA functionality.

Along the same lines, I think the draft should clearly define the
terms AP, base station, AR.  For example, AP has no IP in it, so how
would it would not relate to Mobile IPv6.
AP - a device used to relay packets between radio and wired
     infrastructure and that is not IP-aware.
AR - the device of which address is at the DR of a mobile node.  One
     AR can have several AP's attached to it, one per interface.
XX - a device with both AP and AR functionality.

>    in remote networks (FMIP, HMIP, etc). It's not clear

I thought it refers to HA in foreign nets as part of Mobile IP and not
of FMIP/HMIP.  I would suggest a separate effort to address security
of FMIP/HMIP.

>    is acceptible. My inclination is that strong authentication

Sorry for my ignorance, but what's the concrete difference between
strong and weak auth in this specific context?

>    it SHOULD provide a means on using different algorithms."

Do you think that something else than crypto could be used? I posted
along these lines a while back.  I was arguing that the requirements
should give some freedom to use "functional" mechanisms (not only
crypto) to secure Mobile IP.  There was no feedback about this, so I
suppose there's a common understanding that only crypto would do.

>    later time (ie different RFC).

That is a good argument.  My oppinion too.  However, this would
eliminate HIP, SUCV, PBK-addresses from the first simple solutions.

Alex