Subject: Fwd: [secdir] Rogue Route Advertisement issues

From: Fred Baker <[email-masked]>
Date: Wed, 13 Aug 2008 07:32:44 +1000

I asked the Security Directorate for a review of the RA Guard work,  
and got this review. I have already forwarded it to the authors. The  
question for this house is how the working group would like to respond  
to it. I think they are strong enough comments that the WGLC I planned  
for next week should be put off until the comments are addressed. In  
what way would the operational community recommend addressing them?

Begin forwarded message:

> From: [email-masked] (Sandy Murphy)
> Date: August 13, 2008 3:16:37 AM GMT+10:00
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> 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.
>