Subject: [savi] A loose mode SAVI solution

From: "Guang Yao" <[email-masked]>
Date: Thu, 13 May 2010 13:57:26 +0800

Hi all,

   Besides supplemental binding trigger process, I found maybe "loose mode" 

can also help solve permanent blocking problem.

Existing SAVI mode, which filters packet which doesn't match any

   existing bindings, may fail when bindings are not synchronous with

   the state of hosts. This document specifies a "loose mode" of SAVI,

   which lets pass packet whose source address is not bound with any

   other anchor. Loose mode SAVI is more tolerant in usage of address;

   however, announced ownership of address is still assured.

There is no difference in control plane between loose mode and strict

   mode. In this specified loose mode, bindings are still set up

   primarily based on control packet snooping. Supplemental binding set

   up mechanisms may also be required, including data trigger/counter

   trigger.

   The only difference is in data plane. In strict mode, a packet is

   dropped if its (source address, anchor) pair doesn't match any

   existing binding entry. However, in this loose mode, if only the

   address is not bound with any other anchor, the validation is success

   and the packet should be forwarded.

   Processes of strict mode and loose mode in data plane are listed

   below for comparison:

   Strict mode:

   (1) If (source address, anchor) pair matches an existing binding, let

        pass;

   (2) If (source address, anchor) pair doesn't match any existing

        binding, discard the packet. Data triggered process/counter

        triggered process may be triggered to perform binding set up.

   Loose mode:

   (1) If (source address, anchor) pair matches an existing binding, let

        pass;

   (2) If source address is bound with another anchor, discard the

        packet;

   (3) If source address is not bound with any anchor, let pass the

        packet. No binding set up process is triggered.

   Initial analysis on performance and implementation is contained in the
attached document.

   It is considered to be merged in savi solution for stateless/slaac.

   Welcome any comments.

BR,

Guang

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 07:40:22 -0400

Does this not introduce multi-switch weakness?
We do not have a protocol for coordinating information across SAVI 
switches.  We are relying on the control mechanism.

In this situation, if you have devices hanging off of SAVI switches A 
and B, and a router towards the Internet hanging off some other switch, 
and trusting SAVI, then...
If a device off of switch A gets an address assignment via DHCP, and 
that device only talks to the Internet, then SAVI device B will never 
see any data or control traffic about that assignment.  In "loose" mode, 
that means that switch B would permit a device hanging off of it to use 
that same address, as long as it did not see a DAD conflict.
The same thing can happen with DAD if device B did not see the DAD, or 
if B has reset since A sent the DAD.
This seems to violate the basic model of SAVI.  It confines the 
enforcement zone to a single switch.

Yours,
Joel M. Halpern

Guang Yao wrote:
> 
> 
> Hi all,
> 
>  
> 
>    Besides supplemental binding trigger process, I found maybe “loose mode”
> 
>    Initial analysis on performance and implementation is contained in 
> the attached document.
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 13 May 2010 22:27:30 +0800

Hi Joel,

Thanks for your comments.

A and B are on the same link, and the DAD NS (DAD is also performed on DHCP
address) is a multicast message. If host attached to A performs DAD, the
address will also be bound on the trunk port of B. Then it will not be an
issue.

If A and B are separated at layer 3, then the problem is not in the scope of
SAVI.

BR,
Guang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joel
> M. Halpern
> Sent: Thursday, May 13, 2010 7:40 PM
> To: Guang Yao
> Cc: [email-masked]
> Subject: Re: [savi] A loose mode SAVI solution
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 10:48:45 -0400

Your answer does not address the DHCP case.
Also, the DAD NS can be lost between A and B.
And as I pointed out, B might have reset.

If all we want is single-switch enforcement, then we should say taht. 
But so far, the scope has explicitly been networks with multiple 
switches with leaves attached.

Yours,
Joel

---

From: "Guang Yao" <[email-masked]>
Date: Thu, 13 May 2010 23:12:56 +0800

I don't understand why DHCP case is a problem. DAD will also performed on
DHCP address.

If DAD NS is lost between A and B, host attached to B will be hard to know
what address is bound on A due to the large address space. If DAD NS loss is
a problem, then the DAD NA loss is also a problem in strict mode, as same
address be bound on A and B, but with different hosts. I mean, even in
strict mode, different devices actually works based on unreliable DAD and
decide on their own. As there is no BDP (binding distribution protocol), I
think we should live with that.

If B is reset, loose mode at least has no false positive. Strict mode will
at least filter a certain number of legitimate packet. And binding can also
be recovered from non-violate memory in loose mode.

The advantage of loose mode is that if bindings are incomplete, it will
introduce no false positive but only false negative. In the previous
discuss, false positive is thought to be intolerable. The false negative can
be reduced through actively snooping other control messages and triggering
binding set up process, without fetching packets from the data path.

BR,
Guang

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, May 13, 2010 10:49 PM
> To: Guang Yao
> Cc: [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 11:31:18 -0400

The current assumption is that with DHCP based operation we will not do 
filtering / binding based on DAD.  If we want to change that, we need to 
say so.  I don't see any advantage to complicating life by using both.

Yes, with multi-switch behavior there is some risk if the both the 
original and the potentially duplicate DAD are lost on the itner-switch 
links.  Given that we are not allowed to invent new protocol, there is 
not much choice about accepting that limitation.

If, based on that, we want to narrow our focus, and declare that the 
scope of SAVI si strictly the enforcement within the ports of a single 
switch, then so be it.  But until we make such a decision, it appears to 
be inappropriate to seriously weaken the mechanisms being defined.

This is closely tied to the question of what problem we want to solve. 
For example, assuming a client could force a reset of his directly 
connected SAVI switch, this creates the mis-representation attack whereby:
Malicious client waits for DAD from some other switch,
Malicious client crashes own switch.
After recovery, malicious client starts using other clients Ipv6 address 
to source DoS / malicious packets.
Attack track-back associates problem with wrong client.

One obvious question taht we may want to consider is whether, for SLAAC 
networks, we want to learn from other control messages besdies the 
Neighbor Solicitation message used for DAD.  At least some of the holes 
I can craft can be remediated by paying attention to other control 
messages.  (And in some contexts the RS message is actually the 
important message for communication.)

Yours,
Joel

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 14 May 2010 00:09:10 +0800

(1) Loose mode is designed for stateless /mixed scenario, not for pure DHCP
scenario. I'm sorry for this point is not made clearly. This is mentioned in
the last line of my first post. I admit for pure DHCP scenario, loose mode
is improper and unnecessary.

(2) Loose mode is designed to prevent malicious node from spoofing declared
addresses, but not prevent node from using address whose ownership is not
clear.

(3) For the switch crash problem, I'm afraid the only correct way is
recovering from non-violate memory. If a switch reboots with no state, a
typical attack in both loose mode and strict mode is:
	1. switch crash and reboot;
	2. A legitimate node send DAD NS, or DAD is triggered from data;
	3. The malicious node replies the NS;
	4. switch has trouble to determine who is the first to use the
address
		If it trust the first DAD NS, then the malicious node can
send DAD NS for all the addresses. Because DAD NS is always trusted even a
NA is replied, it will block         other nodes.
        If it trust the NA, then the malicious node is successful in
blocking other nodes.

BR,
Guang

Joel
> M. Halpern
> Sent: Thursday, May 13, 2010 11:31 PM
> To: Guang Yao
> Cc: [email-masked]
> >>>>>    Besides supplemental binding trigger process, I found maybe
"loose
> >>>> mode"

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 12:22:38 -0400

Thank you for the clarification on the intention of application of this.

I will be making a revision of the treat document in the very near 
future.  However, as I understand the threats we claimed to be 
addressing, the adoption of loose mode would significantly reduce the 
threat coverage.

Separately, this discussion does highlight the fact that we need to be 
clear about what coverage we expect in the multi-switch scenarios with 
regard to the DAD-based mechanisms.  (With DHCP, I presume we still 
expect the same degree of coverage, since the DHCP server provides for 
the inter-switch consistency.)

Yours,
Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 May 2010 12:25:23 -0400

My apologies for sloppy typing.

> I will be making a revision of the treat document in the very near 

For clarity, that is the "threat" document I will be revising.
And since the goal of the revision is to match working group intent, if 
folks thing there are threat related issues to be clarified, please say so.

Yours,
Joel

---

From: "Guang Yao" <[email-masked]>
Date: Fri, 14 May 2010 01:30:10 +0800

I think loose mode doesn't reduce the threat coverage significantly. Charter
only requires "prevent nodes attached to the same IP link from
spoofing each other's IP addresses.". Clearly, loose mode can still prevent
nodes from spoofing other' declared IP. For unbound/undeclared IP address,
actually, I believe that if the address ownership is not clear, it may be
dangerous for the savi device to arbitrate the ownership of an address. The
attack mentioned in my last mail may happen.

The most serious problem is, I think, loose mode may be useless in tracking
if a node send data traffic directly.

BR,
Guang

> Sent: Friday, May 14, 2010 12:23 AM
> To: Guang Yao
> Cc: [email-masked]
> >>> decide on their own. As there is no BDP (binding distribution
protocol),
> > I
> >>> discuss, false positive is thought to be intolerable. The false
negative
> > can
> >>>>> A and B are on the same link, and the DAD NS (DAD is also performed
on
> >>>> DHCP
> >>>>> address will also be bound on the trunk port of B. Then it will not
be
> >>> an
> >>>>>> From: [email-masked] [mailto:[email-masked]] On
Behalf
> > Of
> >>>>>>>    primarily based on control packet snooping. Supplemental
binding
> >>> set
> >>>>>>>    (1) If (source address, anchor) pair matches an existing
binding,
> >>> let
> >>>>>>>    (1) If (source address, anchor) pair matches an existing
binding,
> >>> let

---

From: Christian Vogt <[email-masked]>
Date: Mon, 17 May 2010 12:09:48 -0400

On May 13, 2010, Guang Yao wrote:

> can also help solve permanent blocking problem. [...]

Guang:

Please check the mailing list archive for our earlier discussions on
"loose" source address validation.  Particularly relevant hereby is the
discussion on whether or not "unregistered" source addresses should be
protected [1], because loose validation effectively removes the
protection of unregistered source addresses.

Another disadvantage of loose source address validation, besides the
lack of protection of unregistered source addresses, is that the
security perimeter concept cannot be applied to improve scalability. The
consequence is increased memory requirements for SAVI devices, which the
working group deemed unacceptable:  Each SAVI device needs to maintain
bindings for the entire IP link.  And due to the absence of a lifetime
concept for SLAAC-registered addresses, bindings in SLAAC networks must,
in principle, be kept indefinitely.

A third disadvantage is the significant vulnerability to source address
spoofing after a malfunctioning SAVI device has lost state.

Therefore, for loose source address validation to be considered a viable
solution, you would need to convince the working group that:

- lack of protection of unregistered source addresses is acceptable (in
  SLAAC networks),

- sufficient scaling can be achieved,

- binding-loss-related vulnerabilities can be mitigated or justified.

Can you do this?

- Christian

[1] Christian Vogt: Consensus call on "unregistered" source addresses
    http://www.ietf.org/mail-archive/web/savi/current/msg00817.html

---

From: "Guang Yao" <[email-masked]>
Date: Tue, 18 May 2010 15:43:45 +0800

Christian:

Loose mode is an alternative of strict mode, but rather a replacement. Just
as loose mode and strict mode RPF in RFC3704.

Thus, rather than convincing group that loose mode can perfectly handle the
challenges, I would make some comparisons between loose mode and strict
mode.

1. Protection of unregistered address
All the choices when unregistered address appears are:
(1) blocking unregistered address. - cps-00
(2) change implementation structure to recover binding with loss and cost.-
fcfs+ counter. Note that a binding may be hijacked if the host with a
binding is temporary inactive and fail to reply DAD sent by device.
(3) no blocking and no protection: if you want protection, announce it
explicitly. 

2. Scale problem
I understand perimeter is a great idea to share bindings load between savi
devices. However, the traffic from upstream will enter the perimeter without
check for binding is only set up local generated traffic (actually I wonder
if it is possible to separate local traffic from out-link traffic if they
are mixed when arriving savi device). If the upstream traffic spoofs local
address, strict savi will let pass it. Loose mode will at least prevent a
local conflict spoofing.

I know it is out of the scope of savi. However, it shows the scale is
exchanged with local protection and possible configuration complexity.

3. Loss of state
All the choices when states are lost and cannot be recovered from
non-violate memory are:
(1) change implementation structure to recover binding from data with loss
of packets and cost burst on device. Note that attacks may happen.
Refer to
"
If a switch reboots with no state, a typical attack in both loose mode and
strict mode is:
	1. switch crash and reboot;
	2. A legitimate node send DAD NS, or DAD is triggered from data;
	3. The malicious node replies the NS;
	4. switch has trouble to determine who is the first to use the
address
		If it trust the first DAD NS, then the malicious node can
send DAD NS for all the addresses. Because DAD NS is always trusted even a
        NA is replied, it will block other nodes.
        If it trust the NA, then the malicious node is successful in
blocking other nodes.
"
(2) no blocking and no protection. Subsequent DAD is snooped to determine
the ownership of address to recover binding. Bindings are recovered
gradually. Address resolution can be snooped to help recover binding.

In summary, loose mode and strict mode have relative advantages and
disadvantages. It depends on which aspects are more appreciated in the
network.

Best regards,
Guang

> From: Christian Vogt [mailto:[email-masked]]
> Sent: Tuesday, May 18, 2010 12:10 AM
> To: Guang Yao
> Cc: <[email-masked]>