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

From: Phil Roberts <[email-masked]>
Date: Mon, 27 Aug 2001 12:20:40 -0400

Thanks, Alex, for taking the time to review this.  (Some comments
inline)

We would like to encourage feedback from the WG as a whole.  The
security ADs have indicated this is a good start.  Does this reflect
what the working group believes the requirements to be?

Thanks,
Phil

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, August 16, 2001 8:25 AM
> To: [email-masked]
> Subject: [mobile-ip] Comments on
> draft-team-mobileip-mipv6-sec-reqts-00.txt
> 
> 
> Hi,
> 
> I have further comments on this draft that I believe have not yet been
> mentioned.
> 
> -the table in section 6 has threat B.4 but it is not described
>  anywhere in the body.

Good catch.

> -I propose addition of a DoS attack realized by sending fake Binding
>  Acknowledgments (this is also mentioned in
>  draft-roe-mobileip-updateauth-00.txt):
>    Threat B.5:
> 
>    By being able to passively monitor the traffic, the attacker could
>    learn about the CNs that the MN is communicating with and also
>    determine to which CNs the MN is sending BUs.  The attacker could
>    thus synchronize with the MN such that when MN sends a BU to CN
>    then attacker replies to MN with a fake Binding Acknowledgment with
>    a Status field different than 0.
> 
>    Effect B.5:
> 
>    This will cause the MN to resend a new Binding Update (subject to
>    rate limiting of sending BU's) to CN's.  Depending on timing and
>    synchronization, this could result on a DoS or low-grade service:
>    the communication between MN and CN can be shut off or it can
>    follow an unoptimized triangular route.
> 
>    Requirement B.5:
> 
>    I don't know.  Probably the mentionned draft has a good idea in
>    this respect.

This seems like a worthwhile scenario description to add since the MIPv6
draft
already has text for protecting against a malicious binding ack.  Could
you produce proposed requirement text, please?

> 
> -in section 5 Classification of Attackers, after reading the first
>  three lines I'm tempted to understand "link" as a "subnet".  But
>  then, a "link" between CN an HA tends to be interpreted more as a
>  large portion of Internet, including CN's and HA' subnets.  Thus I
>  propose a finer distinction, for example replace:
> 
>   "-  an attacker on the link between the CN and the HA
> 
>    -  an attacker on the link between the MN and the CN"
> 
>  with:
> 
>   "-  an attacker on the path between the CN and the HA (except CN's
>       and HA's links)
> 
>    -  an attacker on the path link between the MN and the CN (except
>       CN's and MN's links)"

This seems like a useful clarification to me.

> 
> Thank you for reading these comments,
> 
> Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: 27 Aug 2001 20:31:34 +0200

Phil Roberts <[email-masked]> writes:
> This seems like a worthwhile scenario description to add since the
> MIPv6 draft already has text for protecting against a malicious
> binding ack.  Could you produce proposed requirement text, please?

When re-reading it I realize that it's poorly formulated, I would
prefer the following:

   Threat B.5:

   By being able to passively monitor the traffic, the attacker could
   learn about the CNs or HA that the MN is communicating with and
   also determine to which CNs or HA the MN is sending BUs.  The
   attacker could thus synchronize with the MN such that when MN sends
   a BU then attacker replies to MN with a fake Binding Acknowledgment
   different than the true Binding Acknowledgment (Status, Lifetime or
   Refresh fields).

   Effect B.5:

   This can lead to (1) MN sends unnecessary BU's (subject to rate
   limiting of sending BU's) or (2) MN doesn't send a BU that is
   necessary.  As further effects of (2) unnecessary triangular
   routing takes place or MN is not reachable at all.

   Requirement B.5:

   Upon receiving a packet carrying a Binding Acknowledgement, a
   mobile node MUST ensure it trusts the sender of that Binding
   Acknowledgment.  Alternatively, the Binding Acknowledgment message
   could be removed from specification so that attacker can't forge
   it.  [I'm not really proposing it, just to say that many things can
   be proposed if we don't have a statement "minimal modifs to Mobile
   IPv6" at the beginning of draft-team].

Alex