Hi,
Here are a couple of comments on the threats doc.
There were some assumptions and even explicit text which
hinted at a
tunnel-based solution... not sure if that is appropriate
substantial
-----------
1) What I'd have liked to see a bit more discussion about
is you'll still need
to be able to perform efficient ingress filtering at ARs.
Traditionally,
it has been possible to spoof intra-link (= ~subnet)
communication. We
don't want to be able to allow that in the whole NetLMM
subnet.
2) I don't understand the big deal about privacy issues.
Most of
these issues are about IP privacy in general and have little
to do
with NetLMM as such. For example in section 6.1 there seems
to be
some discussion about propagation of link-local messages to
figure out
whether the target is on the same link. Well-- you could
get the same
information (depending on mechanisms used) by watching TTLs,
looking
at the latency to your target, try to send a frame to
target's MAC
address directly,etc.
3) I was looking more material on that would answer the
following
quick NetLMM security problem statement I coined up:
"NetLMM makes the subnets larger. There are a lot of
attack vectors
inside a single link and sometimes a single subnet, and many
protocols
make implicit or explicit trust assumptions about these
properties.
Evaluate the most important protocols and see if you can
summarize the
typical security approaches. How does NetLMM make them
worse, and what
needs to happen to mitigate these threats?"
semi-editorial
--------------
Another threat on the interface between access routers
and the MAP is
DoS against network entities. Here, an attacker
manages to obtain a
globally routable IP address of an access router, a MAP,
or some
other network entity, and perpetrates a DoS attack
against that IP
address. In general, NETLMM-based mobility management
is somewhat
more resistant to DoS attacks than host-based localized
mobility
management because nodes within the domain need never
obtain a
globally routable IP address of any entity within the
NETLMM domain.
As a consequence, a compromised node cannot pass such an
IP address
off to an attacker, limiting the ability of an attacker
to extract
information on the topology of the NETLMM domain. It is
still
possible for an attacker to perform address scanning if
access
routers and MAPs have globally routable IP addresses, or
for a
compromise to happen in another way, but the much larger
IPv6 address
space makes address scanning considerably more time
consuming.
Network operators need to take these considerations into
account, and
ensure that their internal network topologies are
sparsely populated.
==> this is IMHO completely irrelevant to NetLMM. These
techniques are
available without NetLMM, and NetLMM does not make them any
worse. So, in
the interest of sticking to the main point -- NetLMM threats
-- I'd remove
this completely.
For packets to be later recognized as coming from the
mobile node, the mobile node's identity is tied to its
IP address, or
possibly to any other identifier which shows up in the
packets (e.g.,
the link-layer address or an IPsec SPI), during the
initial
authentication procedure.
==> I'm not sure how useful an IPsec SPI is, as that may
change frequently
due to automatic IKE re-keying..
A possible mechanism for link-layer authentication is a
combination
of IEEE 802.11i technology and a function in the access
router that
verifies whether or not an inbound packet's IP source
address is
bound to the link-layer encryption keys. At the IP
layer, IPsec AH
provides appropriate protection. Note that IPsec ESP is
not
sufficient as it does not cover a packet's IP header.
==> I'm surprised that you didn't mention PANA and
SEND, as these might be
applicable here.
If an attacker can forge a victim's mobile-node
identifier or
generate packets that appear to originate from the
victim, the
attacker can siphon off packets meant for the victim and
redirect
them to its own location. The perpetrator can inspect
these packets,
effectively waging an "off-path"
eavesdropping attack. However, it
is impossible for the attacker to forward the packets on
to the
victim given that the attacker and the victim use the
same IP
address. The compromised communication session is
therefore highly
likely to abort before the attack causes significant
damage.
==> I'm puzzled by the "However," statement.
Why couldn't the attacker
obtain two IP addresses -- one which it hijacks, and one
which it uses as a
source to communicate with the owner of the IP address. Or
just spoof an
address.
Actually, this attack is described in the next paragraph.
I'd reword these
so that you describe the triangular routing MITM attack
first, as it's the
more useful variant, and then maybe describe what you may be
able to do with
just one IP address.
...
But since packets are tunneled on the sub-
path between the MAP and the mobile node's current
access router, the
acquired information may not be sufficient to actually
locate the
mobile node.
...
This threat can be eliminated by filtering tracing
attempts at the
NETLMM domain gateways.
==> well, if you can find NetLMM node's access router,
that's already
probably sufficiently good indication of where the host is!
==> note that 'filtering tracing options' is by no
means trivial,
because what you'll have to do is basically block any
communication of
ARs to the outside world (no TTL exceeded messages; no
fragmentation
needed messages; no other kind of ICMP messages either).
This might
break IP badly (e.g., if AR has a Path MTU problem due to
tunneling).
9. Informative References
==> some of these should probably be normative..
editorial
----------
Rouge access routers and MAPs can be handled with the
same security
==> s/Rouge/Rogue/
The attacker not necessarily needs to be a customer of
the NETLMM
domain since it does not have to authenticate itself to
the NETLMM
==> s/not necessarily needs/doesn't necessarily need/
4.2 Off-Path Eavesdropping
==> it might be worth clarifying that
"off-path" probably refers to a
different physical link, but the same IP subnet in the
NetLMM domain -- not
off-path in general.
--
Pekka Savola "You each name yourselves
king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings
_______________________________________________
netlmm mailing list
netlmm ngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
|