Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#68 closed defect (fixed)

Security section should discuss MN identity, not security of network elements

Reported by: kempf@… Owned by: kempf@…
Priority: major Milestone:
Component: nohost-req Severity:
Keywords: REQ draft Cc: netlmm@…

Description

Pekka Savola writes:

4) section 2.3 discusses the threat where the MN (or malware at MN) could

reveal information such as IP address which would compomise privacy. I don't think it makes sense to go there here: that's a much much more generic problem, and I'd say that revealing a care-of IP address is the LEAST of your privacy worries if you're infected with malware.

5) the 2nd paragraph of section 2.6 describes that removing MN involvement

in LMM limits the DoS attacks on network infrastructural elements. Like privacy, this is a much more generic problem, and I don't think this is relevant to the requirements. It's easy to find out those infrastructure devices/addresses via other means, or if not, just drop them off the net with a big DDoS attack.

So, I'd completely remove any references to DoS against infrastructure from this section. The existing need of no further security is good enough as it is.

However, you may need to think a bit about what if MN ID mapping techniques / IP address configuration is not secure enough as it is. Then you WILL require "extra" (by some definition) security, or run an insecure network. Hence, in practice, at least in some networks the additional work of security the host-based LMM credentials and securing the MN ID mapping might end up being be equal.

Change History (3)

comment:1 Changed 13 years ago by kempf@…

  • Status changed from new to assigned

The problem here is that, from a cellular network standpoint, MN security is not an issue because the L2 controls who gets on the network, what IP address a terminal gets, and who gets to handover. Most cellular operators are more concerned with the security of the network elements, as described here.

I'm happy to add a paragraph on MN security (and would be even happier to take some suggested text and incorporate it!) but I believe we should leave the text in describing security of network elements as it is a concern to some people, though perhaps not all.

comment:2 Changed 13 years ago by kempf@…

  • Resolution set to fixed
  • Status changed from assigned to closed

I haven't seen any discussion on this, so I am going to remove the text about malware in Section 2.3 and DoS to network elements in Section 2.6.

But at some point, "not going there" isn't going to work for malware. IETF is going to have to deal with malware as a threat in protocol design, as a consequence of end-to-end design. But I'm not going to push this since I want to get this document complete and submitted by the Monteral deadline.

I also added this text to Section 2.6 to discuss the threat of a node trying to change routing for an address that it is not authorized for:

If the access router deduces mobile node movement based on active IP-level >movement detection by the mobile node, then authentication is required for the >IP-level movement detection messages from the mobile node to ensure that the >mobile node is authorized to possess the address used for the movement >detection. The authorization may be at the IP level or it may be tied to the >original network access authentication and wireless link layer authorization >for handover. Some wireless link layers, especially cellular protocols, >feature full support and strong security for handover at the link level, and >require no IP support for handover. If such wireless link security is not >available, however, then it must be provided at the IP level. Security threats >to the NETLMM protocol are discussed in [12].

More details are in the Threats draft (ref. 12).

comment:3 Changed 12 years ago by anonymous

  • Milestone milestone2 deleted

Milestone milestone2 deleted

Note: See TracTickets for help on using tickets.