Subject: FW: [netlmm] Comments on draft-ietf-netlmm-threats-02

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 Aug 2006 07:47:31 -0700

sorry. sent it to the older mailing list.

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Vijay Devarapalli
> Sent: Monday, August 07, 2006 6:41 PM
> To: [email-masked]
> Subject: [netlmm] Comments on draft-ietf-netlmm-threats-02
> 
> Hello,
> 
> I was asked to review draft-ietf-netlmm-threats-02.txt. here
> are some comments.
> 
> I feel the document is incomplete and missing a few things.
> 
> - location privacy. there was a lot of noise made about location
> privacy when the NETLMM work started out. what are the threats?
> what needs to be addressed in the NETLMM protocol work?
> - identifying the mobile node at the MAG. for NETLMM to work it
> is critical that the MAG is able to identify the MN based on
> some identity. there has to be authentication at L2 or L3. is
> confidentiality required? the MAG also need to figure out the
> IP address that corresponds to the mobile node's identity.
> - source address check. for every packet the MAG encapsulates
> and sends to the LMA, it needs to check if the mobile node is
> using the address it is authorized to use. in particular the
> MAG (and the LMA) should prevent a mobile node from using
> another mobile node's address.
> - MN-AR link. is anything assumed about the MN-AR link? whether
> it is a point-to-point link or a broadcast link?
> - the draft does not talk about requiring replay protection for
> MAG-LMA interface or the fact that authentication between LMA
> and MAG is required for all signaling messages
> - how does the LMA check if the MAG is authorized to update
> routing for a particular mobile node? here I am not talking
> about MAG authenticating itself to the LMA. if it is out of
> scope, just mention and then say it is out of scope.
> 
> Vijay
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
> 

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

---

From: Christian Vogt <[email-masked]>
Date: Wed, 09 Aug 2006 00:01:30 +0200

Thanks for the review, Vijay!  Responses in-line...

> what needs to be addressed in the NETLMM protocol work?

We actually had location privacy in the draft in earlier versions until
people felt that it is not NETLMM-specific.  In fact, NETLMM rather
mitigates the location privacy issue to some extent given that MNs
continue to use the same IP address across the entire domain.

The way in which auto-configuration messages (Neighbor Discovery,
Stateless Address Autoconfiguration, MLD, etc.) can be misused for
attacks against location privacy remains the same as in standard IPv6,
with the sole difference that the number of nodes and the geographic
area may be larger in NETLMM than on a typical IPv6 link.  (Although
this difference depends on whether or not these messages are distributed
across the domain by NETLMM core mechanisms.

Other ways through which a MN may be tracked are possible in plain IPv6
as well, so we decided to take the topic out of the draft.

> IP address that corresponds to the mobile node's identity.

Absolutely.  Section 3.1 talks about this, but needs a revision, as
Lakshminath has also pointed out (see
http://www1.tools.ietf.org/wg/netlmm/trac/ticket/113).

> another mobile node's address.

Data plane packet authentication is actually not specific to NETLMM, and
so are IP source address checks.  It's true that MNs must be securely
authenticated during handoff.  But as far as the data plane goes, the
same issues do already exist in plain IPv6.

I should add, however, that ingress filtering is worth being mentioned,
as the NETLMM architecture reduces the preciseness of that technique
(see http://www1.tools.ietf.org/wg/netlmm/trac/ticket/94).

> it is a point-to-point link or a broadcast link?

The draft was written before the current discussion about the addressing
model.  Although no a-priori assumption is made in this regard, we'll go
through the draft again once the discussion on the addressing model
concludes.

> and MAG is required for all signaling messages

Yes, replay protection must be added.  OTOH, sections 2.1 and 2.2
already talk about authentication issues.

> scope, just mention and then say it is out of scope.

You are talking about malicious behavior of an authorized MAG (or LMA),
right?  This is what we mean by compromise in sections 2.1 and 2.2.

Of course, compromise as such is not NETLMM-specific.  But section 2.1
and 2.2 mention it nonetheless along the lines of impersonation.

Alright, thanks again!

- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/