From: sandy@tislabs.com (Sandy Murphy)
Date: August 13, 2008 3:16:37 AM GMT+10:00
To: fred@cisco.com, hartmans-ietf@MIT.EDU
Cc: kurtis@kurtis.pp.se, rbonica@juniper.net, secdir@MIT.EDU
Subject: Re: [secdir] Rogue Route Advertisement issues
I took at look at these two documents, and I have a couple of broad
comments.
The general problem statement in draft-chown-v6ops-rogue-ra-01 says
that
RAs are used during IPv6 auto-configuration. The text does not
mention
what happens to data traffic as the result of the scenarios covered in
section 2. What will a host that ends up configured with two router
addresses and two prefixes do? Run shim6? Could it, would it, send
packets to the incorrect router address? (I expect so, so maybe
this is
just considered too obvious to state. High potential of being a
really
clueless question here.)
The mitigation techniques in general sound sort of stop-gap. They may
be better than nothing, but not particularly effective against a
deliberate attack. Furthermore, some of the techniques seem to work
contrary to the stated motivation of using RAs - autoconfiguration.
However, the description in section 2.2 of
draft-chown-v6ops-rogue-ra-01 of the Windows 6to4 gateway sounds like
a lurking common operational problem that deserves operational
solutions that don't have to be particularly effective against
deliberate attack. (Is this Vista only?)
In draft-ietf-v6ops-ra-guard-00.txt, the descriptions of the threat
talk include malicious intent, but the techniques presented would not
be effective against malicious attack.
Is the RA guard supposed to work in mixed environments in which some
hosts are SeND capable and some are not? What happens if the host and
guard decisions are different (perhaps not a problem if the guard is
blocking RAs the host would otherwise have accepted).
The criteria the RA guard is proposed to use are criteria that could
be easily spoofed - L3 address, L2 MAC, etc. So this is not effective
against a deliberate attack (as already mentioned). By the way,
section
2 says "If this node-in-the-middle is a L2 device" -- in the rest of
the
document, the RA guard is spoken of as a L2 device. Is it ever not a
L2 device?
The "learning" state and interface type are not well explained.
What is
being learned and how and when is it used?
The text talks about the RA-guard choosing to block or forward RAs for
some time until a decision is made concerning their validity. What is
the reason for the delay? Is this something to do with certificate
retrieval in the SeND case?
The whole state transition section is quite confusing. Part of the
confusion is the use of state names and interface types that are
similar. The need for both is not clear. When a node is in Learning
state, are all the interfaces in Learning mode? When an interface
transitions to Blocking or Forwarding mode, does the state always
transition to ACTIVE mode?
=============================
draft-chown-v6ops-rogue-ra-01
In section 3.2, are there ways to characterize the situations in which
SeND is not able to use SeND?
In section 3.4:
Thus an administrator could use High settings for
managed RAs, and hope that 'accidental' RAs would be medium
priority,
and that hosts implemented this optional protocol.
"Hope" is not generally considered an effective security
mechanism. :-)
(or an effective operational mechanism, I would think.)
In section 3.5:
Ideally authentication would be
mutual. This may mitigate against a malicious attacker, but doesn't
address the misconfiguration issues.
Unless of course we're talking about byzantine behavior, where the
malicious attacker is an authentic network device.
In section 3.7:
It could be possible to run a daemon on a link (perhaps on the
router
on the link) to watch for incorrect RAs and to send a deprecating RA
with router lifetime of zero when such an RA is observed.
This does not discuss how the daemon spots incorrect RAs - presumably
by being configured with a list of known correct sources of RAs, which
then has the difficulties with dynamic router interface addresses as
section 3.6 but may be easier to keep current as it is a centralized
system (fewer nodes to individually configure). Unless of course, its
own default gateway is the one whose interface changed, in which case
hands on would be the only recourse. I'm guessing here.
What happens if there are two daemons running? What if there is one
attack daemon targeting legitimate RAs?
Section 4:
One is that it would generally be prudent for network monitoring or
management platforms to be able to observe and report on observed
RAs, and whether unintended RAs (possibly from unintended sources)
are present on a network. Further, it may be useful for individual
hosts to be able to report their address status, e.g. this could be
useful during an IPv6 renumbering phased process as described in
RFC4192 [5].
If the node reporting is a node whose router address or prefix has
been
affected, could its ability to report be hampered?
=====================================
draft-ietf-v6ops-ra-guard-00.txt
What are the nd-proxy pitfalls? Is there a reference?
The RA guard is spoken of as making life easier even in SeND
environments - how do the hosts themselves know that they need not
check
RAs? Would configuration of the guard have to be accompanied by host
configuration to turn SeND off? What happens if the host and RA guard
both do SeND and for some reason disagree?
In the LEARNING state (section 3.2) and the RA-Learning interface
(section 4.3), what is being learned? Section 3.2 talks about
"actively
acquiring information about the devices connected to its interfaces",
but the potential criteria mentioned do not seem to require any info
gathering. Is this talking about retrieving certificates when SeND is
enabled?
In Section 4.1, RA-Blocking interface - are *all* RAs blocked?
Valid or
not? Is there a difference between not having the RA-Guard capability
activated on a device and having RA-Blocking interfaces?
The whole state transition section is quite confusing, e.g., a node
"could be set in RA- Blocking mode and enabled for forwarding by the
network administrator" How does this relate to the states of OFF,
LEARNING and ACTIVE? Is enabled for forwarding the same as being an
RA-Forwarding interface? How is a node in "Blocking mode" and
"enabled
for forwarding" at the same time? Part of the confusion is the use of
state names and interface types that are similar. The need for both
is
not clear.