Subject: [savi] Review: draft-ietf-savi-fcfs-03.txt

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 6 Jul 2010 18:25:40 +0200

Hi,

please, find my review of this document:

FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally
                           Assigned Addresses
                        draft-ietf-savi-fcfs-03

[snip]

2.2.  Constraints for FCFS SAVI

   FCFS SAVI is designed to be deployed in existing networks requiring a
   minimum set of changes.  For that reason, FCFS SAVI does not require
   any changes in the hosts which source address is to be verified.  Any
   verification must solely rely in the usage of already available
   protocols.  This means that FCFS SAVI cannot define a new protocol
   nor define any new message on existing protocols nor require that a
   host uses an existent protocol message in a different way.  In other
   words, the requirement is no host changes.

   FCFS SAVI validation is performed by the FSFC SAVI function.  Such

<JMC>
Typo? s/FSFC SAVI function/FCFS SAVI function
<JMC>

   function can be placed in different type of devices, including a
   router or a layer-2 bridge.  The basic idea is that the FCFS SAVI
   function is located in the points of the topology that can enforce
   the correct usage of source address by dropping the non-compliant
   packets.

2.3.  Address ownership proof

[snip]

   There are however additional considerations to be taken into account.
   For instance, consider the case of a host that moves from one segment
   of a LAN to another segment of the same subnetwork and it keeps the
   same IP address.  In this case, the host is still the owner of the IP
   address, but the associated layer-2 information has changed.  In
   order to cope with this case, the defined FCFS SAVI behaviour implies
   the verification whether the host is still reachable using the
   previous layer-2 information.  In order to do that FCFS SAVI uses ND

<JMC>
s/ND/Neighbor Discovery (ND)
<JMC>

   protocol.  If the host is no longer reachable at the previously
   recorded layer-2 information, FCFS SAVI assumes that the new location
   is valid and creates a new binding using the new layer-2 information.
   In case the host is still reachable using the previously recorded
   information, the packets coming from the new layer-2 information are
   dropped.

[snip]

2.5.  Special cases

   The following special cases that need to be considered
   o  Hosts with multiple physical interfaces connected to the same
      link.
   o  Anycast i.e. multiple hosts using the same source address to send
      packets.

<JMC>
What are the cases you have in mind where the source address is an
anycast address?
<JMC>

   o  Proxy ND i.e. host sending packets on behalf of other, in a
      layer-3 transparent manner.

<JMC>
To add: Optimistic Duplicate Address Detection (DAD) [RFC4429]
<JMC>

3.  SAVI topology and port configuration

3.1.  SAVI enforcement perimeter

[snip]

   One possible approach would be for every SAVI device to store binding
   information about every source addresses in the subnetwork This means

<JMC>
s/"in the subnetwork This means"/"in the subnetwork. This means"
<JMC>

   that every SAVI device would store binding for each source address to
   the local layer-2 anchor through packets with that source address can
   be received through.  The problem with this approach is that it
   imposes significant memory burden on the SAVI devices.  In order to
   reduce the memory requirements imposed to each device, the SAVI
   solution described in this specification distributes the storage of
   SAVI binding information among the multiple SAVI devices of a
   subnetwork.  The SAVI binding state is distributed across the SAVI
   devices according to the following criteria: each SAVI device will
   store binding information about the source addresses bound to layer-2
   anchors corresponding to the interfaces that connect to the part of
   the topology that is outside of the SAVI enforcement perimeter.
   Since all the untrusted packet sources are by definition in the
   external part of the perimeter, this means that the packets generated
   by each of the untrusted sources will reach the perimeter through one
   interface of a SAVI device.  The binding information for that
   particular source address will be stored in this first SAVI device
   the packet reaches to.

   This means the SAVI binding information will be distributed across
   multiple devices.  In order to provide proper source address
   validation, it is critical that the information distributed among the
   different SAVI devices is coherent.  In particular, it is important
   to avoid that the same source address is bound to different layer-2
   anchors in different SAVI devices.  Should that occur, then it would
   mean that two hosts are allowed to send packets with the same source
   address, which is what we are trying to prevent.  In order to
   preserve the coherency of the SAVI bindings distributed among the
   SAVI devices within a realm, the Neighbour Discovery (ND) protocol is
   used, in particular the Neighbour Solicitation (NSOL) and Neighbour
   Advertisement (NADV) messages.  Before creating a SAVI binding in the
   local SAVI database, the SAVI device will send a NSOL message
   querying for the address involved.  Should any host reply to that
   message with a NADV message, the SAVI device that sent the NADV will
   infer that a binding for that address exists in another SAVI device
   and will not create a local binding for it.  If no NADV message is
   received as a reply to the NSOL, then the local SAVI device will
   infer that no binding for that address exists in other SAVI device
   and will create the local SAVI binding for that address.  (NOTE that
   the description included here is overly simplified to illustrate the
   mechanism used to preserve the coherency of the binding databases of
   the different SAVI devices.  The actual SAVI mechanism as described
   below varies in the fact that in some cases it is the SAVI device
   that generates the NSOL while in other cases it simply forwards the
   NSOL generated by the end host, and that the SAVI device will send
   multiple copies of the NSOL in order to improve the reliability of
   the message exchange).

<JMC>
Maybe as this is an example, move this previous paragraph in an Appendix.
BTW, it is unclear for me whether the ND signaling, to check whether a
binding already exists or not, is either only between SAVI devices or
between the SAVI device and hosts.
<JMC>

[snip]

   Trusted ports are used for connections with trusted infrastructure,
   including the communication between SAVI devices, the communication
   with routers and the communication of other switches that while they

<JMC>
IMHO, trusting routers, that are not in the SAVI enforcement
perimeter, all the time may be a bad idea:
(1) A compromised router can send packets with a spoofed IP source address
(2) Routers can also be a host (e.g. NEMO MR, Home Gateway)
<JMC>

   are not SAVI devices, they only connect to trusted infrastructure
   (i.e. other SAVI devices, routers or other trusted nodes).  So, in
   the figure above, Port 3 of SAVI1 and port 1 of SAVI3 are trusted
   because the connect two SAVI devices.  Port 4 of SAVI1, port 3 of
   SAVI2, port 2 of SAVI3 and port 1 of SAVI4 are trusted because the
   connect to SWITCH-A to which only trusted nodes are connected.  In
   the figure above, port 2 of SAVI2 and port 3 of SAVI3 are trusted
   ports because they connect to routers.

[snip]

3.2.  SAVI port configuration guidelines

   The guidelines for port configuration in SAVI devices are:
   o  Ports that are connected to another SAVI device SHOULD be
      configured as Trusted ports.  Not doing so will at least
      significantly increase the memory consumption in the SAVI devices.
   o  Ports connected to hosts SHOULD be configured as Validating ports.
      Not doing so will allow the host connected to that port to send
      packets with spoofed source address.
   o  Ports connected to routers SHOULD be configured as Trusted ports.
      Configuring them as Validating ports would increase the signaling
      due to SAVI.  The implication is that a router can generate
      traffic with any source address as they are assumed to be part of
      the trusted infrastructure.

<JMC>
cf. my previous comment.
Proposal: s/"Ports connected to routers SHOULD be configured as
Trusted ports"/"Ports connected to routers MAY be configured as
Trusted ports"
<JMC>

   o  Ports connected to a chain of one or more legacy switches that
      have hosts connected SHOULD be configured as Validating ports.
      Not doing so will allow the host connected to any of these
      switches to send packets with spoofed source address.
   o  Ports connected to a chain of one or more legacy switches that
      have other SAVI devices and/or routers connected but had no hosts
      attached to them SHOULD be configured as Trusted ports.  Not doing
      so will at least significantly increase the memory consumption in
      the SAVI devices and increase the signaling traffic due to SAVI
      validation.

<JMC>
cf. above
Proposal: s/"Ports connected to a chain of one or more legacy switches
that have other SAVI devices and/or routers connected but had no hosts
attached to them SHOULD be configured as Trusted ports."/"Ports
connected to a chain of one or more legacy switches that have other
SAVI devices connected but had no hosts/routers attached to them
SHOULD be configured as Trusted ports. If routers are attached, ports
connected MAY be configured as Trusted ports."
<JMC>

[snip]

4.2.1.  Processing of transit traffic

   The FCFS SAVI function is located in a forwarding device, such as a
   router or a layer-2 bridge.  The following processing is performed
   depending on the type of port the packet has been received through:

   o  If the data packet is received through a Trusted port, the data
      packet is forwarded and no SAVI processing performed to the
      packet.
   o  If the data packet is received through a Validating port, then the
      SAVI function checks whether the received data packet is local
      traffic or transit traffic.  It does so by verifying if the source
      address of the packet belongs to one of the directly connected
      prefixes available in the receiving interface.  It does so by
      searching the FCFS SAVI Prefix List.
      *  If the IP source address does not belong to one of the local
         prefixes of the receiving interface, this means that the dat

<JMC>
s/"this means that the dat"/"this means that the data"
<JMC>

         packet is transit traffic and the packet SHOULD be discarded.

<JMC>
IMHO, the packet should not be discarded but should be checked by
Ingress Filtering mechanisms [BCP38][BCP84]. BTW, that demonstrates
the complementarity between SAVI mechanisms and Ingress Filtering
mechanisms.
Proposal: s/"packet is transit traffic and the packet SHOULD be
discarded."/"packet is transit traffic and, if available, Ingress
Filtering mechanisms [BCP38][BCP84] SHOULD examine this packet."
<JMC>

         The FCFS SAVI function MAY send an ICMP Destination Unreachable
         Error back to the source address of the data packet.  (ICMPv6,
         code 5 (Source address failed ingress/egress policy) should be
         used).

<JMC>
So (cf. my previous comment), I would remove the text below.
<JMC>

      *  If the source address of the packet does belong to one of the
         prefixes available in the the receiving port, then the SAVI
         local traffic validation processes is executed as described
         below.

4.2.2.  Processing of local traffic.

[snip]

   TESTING_TP: A binding for a source address enters in this sate when a

<JMC>
s/"enters in this sate"/"enters in this state"
<JMC>

   DAD_NSOL has been received through a Trusted port. this implies that

<JMC>
s/"this implies that"/"This implies that"
<JMC>

   another host is performing the DAD procedure for that source address
   in another switch. this may due to an attack or to the fact that the

<JMC>
s/"this may due"/"This may due"
<JMC>

   host may have moved.  The binding in this state is then being tested

<JMC>
BTW, maybe, this may due also just because another host tries to
configure an address already used (i.e. collision)?
<JMC>

   to determine which is the situation.

   TESTING_TP: A binding for a source address enters in this sate when a

<JMC>
s/TESTING_TP/TESTING_VP
s/"A binding for a source address enters in this sate when a"/"A
binding for a source address enters in this state when a"
<JMC>

   DAD_NSOL or a data packet has been received through a Validating
   port. this implies that another host is performing the DAD procedure
   for that source address in another switch. this may due to an attack

<JMC>
"another host is performing the DAD procedure for that source address
in another switch."
As the DAD_NSOL/data packet is received on the Validating port, I
don't understand why it is said that the host is attached on another
switch. May you clarify this, please?
<JMC>

   or to the fact that the host may have moved.  The binding in this
   state is then being tested to determine which is the situation.

   TESTING_LIFETIME: A binding for a source address is in this state
   cause the lifetime of the entry is about to expire. this is due to

<JMC>
s/this is due to/This is due to
<JMC>

   the fact that no packets has been seen by the SAVI device for the
   LIFETIME period. this may be due to the host simply being silent or

<JMC>
s/this may be due to/This may be due to
<JMC>

   because the host has left the location.  In order to determine which
   is the case, a test is performed, in order to determine if the
   binding information should be discarded.

   We describe next how the different inputs are processed depending on
   the state of the binding of the IP address.

   A simplified figure of the state machine can be found at
   http://www.it.uc3m.es/~marcelo/SAVI_state_machine.pdf

<JMC>
Maybe add this state machine as an Appendix because that really helps
to understand all the transition states :)
<JMC>

   NO_BIND

   o  Upon the reception through a Validating Port (VP) of a Neighbour
      Solicitation (NSOL) generated by the Duplicate Address Detection
      (DAD) procedure (hereafter named DAD_NSOL) containing Target

<JMC>
As the term "DAD_NSOL" is used before, maybe move the definition before.
<JMC>

      Address IPAddr, or after the reception of a DATA packet containing
      IPAddr as the source address, the SAVI device will execute the
      process of sending Neighbour Solicitation (NSOL) messages of the
      Duplicate Address Detection process as described in section 5.4.2
      of [RFC4862] for the IPAddr using the following default

<JMC>
I don't understand why the reception of a DAD_NSOL should trigger the
sending of another DAD_NSOL message. Is it because you drop the one
sent by the host?
Why you don't want just to watch ND exchanges?
<JMC>

      parameters: DupAddrDetectTransmits set to 2 (i.e. 2 Neighbour
      Solicitation messages for that address will be sent by the SAVI
      device) and RetransTimer set to 500 milliseconds (i.e. the time
      between two Neighbour Solicitation messages is 500 millisecs and
      also the wait time for replies in the form of Neighbour
      Advertisement for the queried address).  The NSOL messages are not

<JMC>
I assume you mean DAD_SOL? Or do you differentiate DAD_NSOL, message
sent by a host, and NSOL, message sent by a SAVI device?
<JMC>

      sent through any of the ports configured as Validating Ports.  The
      NSOL messages are sent through the proper Trusted Ports (as
      defined by the switch behaviour that will depend on whether it
      performs MLD snooping or not) The SAVI device MAY discard the data
      packet while the DAD procedure is being executed.
      *  EDITOR NOTE: We need to rate limit the emission of NSOL of the
         SAVI device as a whole.
      *  EDITOR NOTE 2: should we send the NSOL through the port the
         packet was received through?

<JMC>
IMHO, if the SAVI device has lost all the bindings (e.g. due to a
crash) and, in fact, had already before a binding for this
IPAddr/Port, if the action is triggered by a data packet, it should
send the DAD_NSOL through this port to regenerate the binding.
<JMC>

      The state is moved to TENTATIVE.  The LIFETIME is set to TENT_LT
      (i.e.  LT==TENT_LT) and the LAYER_2 ANCHOR is set to VP (i.e.
      P==VP)

<JMC>
What is the default value for TENT_LT?
<JMC>

   o  Data packets containing IPAddr as the source address received
      through Trusted ports are processed and forwarded as usual (i.e.
      no special SAVI processing)
   o  DAD_NSOL packets containing IPAddr as the target address received
      through a Trusted port are NOT forwarded through any of the
      Validating ports but they are sent through the proper Trusted
      Ports (as defined by the switch behaviour that will depend on
      whether it performs MLD snooping or not)

<JMC>
I don't understand why DAD process can no more be performed between
hosts (i.e. if H1 is performing DAD for a tentative address not
already used by other hosts, so no Bindings in SAVI2/SAVI3/SAVI4, all
the DAD_NSOL sent by H1 will not arrive to the other hosts): are you
sure that there is no bad consequence?
<JMC>

   o  Neighbor Advertisement packets sent to all nodes as a reply to the
      DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the
      target address coming through a Validating port are discarded.

<JMC>
I don't understand why there is this rule (if this is a reply to a
DAD_SOL, that means that the STATE is at least TENTATIVE if DAD_NSOL
is allowed to go through Validating Port - BTW, which is not allowed
as described before): may you clarify?
Another point is, AFAIK, with such a rule you cannot differentiate a
Solicited NA message replying to NS message sent for DAD from an
Unsolicited NA message (e.g. the Link-Layer address of the host has
changed and the host wants to advertise the new one).
<JMC>

   o  Other signaling packets are processed and forwarded as usual (i.e.
      no SAVI processing)

   TENTATIVE

   o  If the LIFETIME times out, the state is moved to VALID.  The
      LIFETIME is set to DEFAULT_LT (i.e.  LT== DEFAULT_LT).  Stored
      data packets are forwarded (if any).

<JMC>
What is the default value for DEFAULT_LT?
I may assume that this could be the lifetime of the prefix (when this
is for a global unicast address) but what is this value for a
link-local address (e.g. infinite as the lifetime for fe80::/64 is
infinite)?
<JMC>

   o  If a Neighbour Advertisement (NADV) is received through a Trusted
      Port with Target Address set to IPAddr, then state is set to
      NO_BIND and the LAYER_2 ANCHOR and the LIFETIME are cleared.  Data
      packets stored corresponding to this binding are discarded.

   o  If a NADV is received through a Validating Port with Target
      Address set to IPAddr, the NADV packet is discarded

<JMC>
I don't understand this rule.
Assume the following scenario:
- H1 generates a tentative address IP@ and performs DAD
- DAD succeeds and so SAVI1 has the Binding (IP ADDRESS = IP@, LAYER_2
ANCHOR = 1, STATE = VALID)
- SAVI1 loses its Bindings (e.g. SAVI1 crash)
- H2 generates a tentative address IP@ (the same as the one owned by H1)
- H2 performs DAD and SAVI1 has the Binding (IP ADDRESS = IP@, LAYER_2
ANCHOR = 2, STATE = TENTATIVE)
- H1 replies with a DAD_NADV but this message will be dropped by SAVI1
Consequences: H1 and H2 will own the same IP address (and H1 will no
more able to use it).
<JMC>

   o  If a data packet with source address IPAddr is received with
      Layer_2 anchor equal to P, then the packet is either stored or
      discarded.

<JMC>
I assume that the different cases are the ones described below. Correct?
If so, IMHO, this sentence may be removed.
<JMC>

      *  EDITOR NOTE: we need to define a maximum storage space for the
         data packets.  Having a single default value may be hard since
         it will heavily depend on the capability of the device.  Maybe
         it would be enough that the device has a maximum and that the
         value can be configured?
   o  If a data packet with source address IPAddr is received through a
      Trusted port, the data packet is forwarded. the state is

<JMC>
s/the state is/The state is
<JMC>

      unchanged. ( waiting for the NADV?)
   o  If a data packet with source address IPAddr is received through a
      Validating port other than P, the data packet is discarded.

<JMC>
What does happen when a data packet with source address IPAddr is
received through a Validating port equal to P?
<JMC>

   o  Other signaling packets are processed and forwarded as usual (i.e.
      no SAVI processing)
      *  EDITOR NOTE: this may need more thought

<JMC>
Maybe to look at the case when 2 hosts performs DAD for the same IP
address at the same time (i.e. a DAD_NSOL is received on a
Trusted/Validating Port)
<JMC>

   VALID

   o  If a data packet containing IPAddr as a source address arrives
      from Validating port P, then the LIFETIME is set to DEFAULT_LT and
      the packet is forwarded as usual.
      *  EDITOR NOTE: Is this feasible? i.e. to reset a timer each time
         a data packet arrives?  We could just have a long lifetime and
         actively check for the host when the lifetime is about to
         expire.
<JMC>
A potential solution would be to set DEFAULT_LT equal to the prefix
Valid Lifetime and, when LIFETIME expires, to check (as described
below) whether the address is still used or not (i.e. the SAVI device
sends a DAD_NSOL). Now, for link-local addresses, as the Valid
Lifetime is infinite, that should not work ... :(
<JMC>

   o  If a DAD_NSOL is received from a Trusted port, then the DAD_NSOL
      message is forwarded to port P and it is also forwarded to the
      proper Trusted Ports (as defined by the switch behaviour that will
      depend on whether it performs MLD snooping or not).  The state is
      changed to TESTING_TP.  The LIFETIME is set to TENT_LT.

<JMC>
What is the default value for TENT_LT?
<JMC>

[snip]

   TESTING_TP

   o  If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the
      state is changed to NO_BIND
   o  If a NADV message containing the IPAddr as target address is
      received through the Validating port P as a reply to the DAD_NSOL
      message, then the NADV is forwarded as usual and the state is
      changed to VALID.  The LIFETIME is set to DEFAULT_LT
   o  If a data packet containing IPAddr as the source address is
      received through port P, then the packet is forwarded.
      *  EDITOR NOTE: should we move back to VALID?

<JMC>
As the host has been able to perform DAD before (i.e. as result,
creation of a Binding in the SAVI device), the same device should be
able to reply to the DAD_NSOL with a DAD_NADV: so, unless there is a
specific case I missed, I would suggest to keep the STATE to
TESTING_TP
<JMC>

   o  If a data packet is received through a port that is other than
      port P, then the packet is discarded.

   TESTING_VP

   o  If the LIFETIME expires, the LAYER_2 ANCHOR set to P' (i.e.
      P==P'), the LIFETIME is set to DEFAULT_LT and the state is changed

<JMC>
I would remove "(i.e. P==P')", because that may introduce confusion
(i.e. P is equal to P', which is not the case in fact) and I would do
the following change:
s/the LAYER_2 ANCHOR set to P'/the LAYER_2 ANCHOR is modified from P to P'
<JMC>

      to VALID.  Data packet stored coming from P' are forwarded.
   o  If a NADV message containing the IPAddr as target address is
      received through the Validating port P as a reply to the DAD_NSOL
      message, then the NADV is forwarded as usual and the state is
      changed to VALID.  The LIFETIME is set to DEFAULT_LT
   o  If a data packet containing IPAddr as the source address is
      received through port P, then the packet is forwarded.
      *  EDITOR NOTE: should we move back to VALID?

<JMC>
Same comment as for TESTING_TP case
<JMC>

   o  If a data packet is received through a port that is other than
      port P, then the packet is discarded.

   TESTING_LIFETIME

   o  If the LIFETIME expires, the LAYER_2 ANCHOR is cleared and the
      state is changed to NO_BIND
   o  If a NADV message containing the IPAddr as target address is
      received through the Validating port P as a reply to the DAD_NSOL
      message, then the NADV is forwarded as usual and the state is
      changed to VALID.  The LIFETIME is set to DEFAULT_LT
   o  If a data packet containing IPAddr as the source address is
      received through port P, then the packet is forwarded and the
      state is changed to VALID.  The LIFETIME is set to DEFAULT_LT

<JMC>
Same comment as for TESTING_TP case (i.e. regarding "move back to VALID STATE")
<JMC>

   Rate limiting of messages: TBD

   MLD considerations

   The SAVI device must join the Solicited Node Multicast group for all
   the addresses which state is other than NO_BIND. this is needed to
   make sure that the SAVI device will receive the DAD_NSOL for those
   addresses.  Please note that it may not be enough to relay on the
   host behind the Validating port doing so, since the node may move and
   after a while, the packets for that particular solicited node
   multicast group will no longer be forwarded to the SAVI device.  So,
   the SAVI device SHOULD join the solicited node multicast groups for
   all the addresses that are in a state other than NO_BIND

<JMC>
I am clearly not expert with MLD, but to receive DAD_NSOL messages
(especially when the IPAddr in the DAD_NSOL has a state equal to
NO_BINDING, and so to trigger the process from NO_BINDING state to
TENTATIVE state), is it not necessary for the SAVI device to join
Solicited Node Multicast group for all the potential addresses?
<JMC>

Hope that helps and thanks in advance for your reply.

Best regards.

JMC.


2010/5/13  <[email-masked]>:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Source Address Validation Improvements Working Group of the IETF.
>
>
>        Title           : FCFS-SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned Addresses
>        Author(s)       : E. Nordmark, et al.
>        Filename        : draft-ietf-savi-fcfs-03.txt
>        Pages           : 19
>        Date            : 2010-05-13
>
> This memo describes FCFS SAVI a mechanism to provide source address
> validation for IPv6 networks using the First-Come First-Serve
> approach.  The proposed mechanism is intended to complement ingress
> filtering techniques to provide a higher granularity on the control
> of the source addresses used.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-savi-fcfs-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Jul 2010 17:20:11 +0200

Hi Jean Michel,

Thanks for the review

see replies below....

> Typo? s/FSFC SAVI function/FCFS SAVI function
typo fixed

> s/ND/Neighbor Discovery (ND)
done
> What are the cases you have in mind where the source address is an
none in particular, i included this here just as a flag to think about this.
I mean, this can potentially require two hosts being able to own the 
same address, which is unlikely to be supported by SAVI.

> To add: Optimistic Duplicate Address Detection (DAD) [RFC4429]
done

> s/"in the subnetwork This means"/"in the subnetwork. This means"
done

> Maybe as this is an example, move this previous paragraph in an Appendix.
Well, it is not an example. It is an intuitive overview of what is going 
on, which imho helps the reader to get a grasp of the protocol. That is 
the goal of this section, provide an insight of the protocol, so we can 
later on dive into the actual normative spec, which cannot be as 
intuitive, cause needs to be very precise. For that reason, i woudl 
rather keep it here. makes sense?

> between the SAVI device and hosts.
mmm, how come?

The text reads:

  Before creating a SAVI binding in the local SAVI database, the SAVI 
device will send a NSOL message querying for the address involved. 
Should any host reply to that message with a NADV message, the SAVI 
device that sent the NADV will infer that a binding for that address 
exists in another SAVI device and will not create a local binding for it.

So, the SAVI device sends the RSOL and the hosts (may) reply. What 
additional clarification do you think it is needed?
> (2) Routers can also be a host (e.g. NEMO MR, Home Gateway)
The problem is that a router may need to be able to forward packets from 
on link hosts (and eventually sending a redirect to the originating host)

I mean, suppose that a host sends a packet to an on-link host through a 
router. This is actually supported in current specs afaict. The router 
then would forward the packet and send a redirect. If we attach the 
router to a validating por, it wouldn't be able to do so.

Besides, if the router is compromised, you are in very bad shape in any 
case. I mean, first the router by definition can spoof any off link 
address. BEsides, it can send any RADV, for instance, the router can 
start sending RADV, claiming that all prefixes are off link, so all 
traffic goes through the router.

So, i am not convinced yet about doing this....
> Trusted ports"/"Ports connected to routers MAY be configured as
As i mention above, i am not conviced this is the way to go.
If we decided we want to have validation of the local transit generated 
by the router, then we would need to define another type of port called 
Router Port, which would allow transit traffic but would validate local 
traffic. This would result in additional complexity i.e. it is not only 
setting the router port to  validating port, since these ports don't 
allow to send transit traffic.

> connected MAY be configured as Trusted ports."
same as above

> s/"this means that the dat"/"this means that the data"
done
> IMHO, the packet should not be discarded

mmm, i think the situation is slightly more complex than that.
If a transit packet is received through a port that has not been 
configured to connect to a router, then the packet must be discarded, as 
the text states. I think what you are suggesting actually affects to the 
other bullet, i.e. the case that the packet is received through a port 
that is connected to a router. In this case, the packet is allowed by 
the SAVI device, but it would certainly be useful to perform the 
additional checks resulting from ingress filters.

So, in brief, transit packets coming to the SAVI device through ports 
that are not configured to connect to a router must be discarded as 
defined. Ingress filtering processing makes sense in transit packet 
received through ports that are configured to be connected to routers 
(i.e. the first bullet)

>   but should be checked by

mmm, is not that i disagree with the intention here, but i was operating 
under the assumption that SAVI and ingress filtering were kind of 
orthogonal and that using them together made sense but was more an 
operational decision. This basically means that we should refrain from 
recommending the use of ingress filtering in the SAVI spec.

In particular, the current draft reads:

Transit traffic generated by a router would be verified using alternative techniques, such as ingress filtering.

But not more than that.

Besides, the problem is that the SAVI function can be implemented in a 
device that is not a router. So, including a SHOULD would basically 
reccommend that any SAVI device implements the oruter functions i.e. has 
routing tables.
So, i would rahter not do this.

> So (cf. my previous comment), I would remove the text below.
mmm, as i mentioned above, in this case, the packet must be discarded, 
since it comes from a port which is not supposed to connect to a router.

> s/"enters in this sate"/"enters in this state"
done
> s/"this implies that"/"This implies that"
done

> s/"this may due"/"This may due"
done

> configure an address already used (i.e. collision)?
agree, added that

> binding for a source address enters in this state when a"
done
> switch. May you clarify this, please?

I have rephrased that to "another port"
> to understand all the transition states :)
Right, this is my plan, but i will do that once the state machine is 
stable. It is much easier to modify a ppt than the ascii art.

> As the term "DAD_NSOL" is used before, maybe move the definition before.
expanded the previous usage of the expression
> Why you don't want just to watch ND exchanges?
the thing is that since we are using the DAD msgs to synchronize SAVI 
device state, we want to make it more reliable, so instead of simply 
forwarding the DAD NSOL, we send it twice. You can see it as forwarding 
the initial one and sending one more copy. I have tried to capture that 
in the text by simply stating that the process of sending DAD NSOL is 
executed with a given set of paramters.

I have added the following clarification:

     In the case of the DAD_NSOL message, this is equivalent to sending 
the receiving message twice.
> I assume you mean DAD_SOL?
yes, changed that

>   Or do you differentiate DAD_NSOL, message
not defined yet, any suggestion?

> hosts
well, that is not exactly the case.
This behaviour basically enforces that only hosts which have a binding 
for a given address in the SAVI switch can defend an address.

> (i.e. if H1 is performing DAD for a tentative address not
> the DAD_NSOL sent by H1 will not arrive to the other hosts):
but why would the other hosts need to receive the DAD packet? since they 
do not own that address, i mean?

> are you
> DAD_SOL, that means that the STATE is at least TENTATIVE
no, the state for this address is NO BIND (i.e. this text is located in 
the NO BIND state processing)

So, the point is that if a SAVI switch receives a Neighbour Adv for an 
address for which it has no binding, it doens't forward the packet to 
any of the validating ports, as this cannot be a reply to a DAD NSOL 
from the, since there is no SAVI state for that address.

If the state is tentative, then this is described in the tentative state 
and RADV is forwarded.
>   if DAD_NSOL

> changed and the host wants to advertise the new one).
Yes, you can distinguish them cause there is the unsolicited flag on the 
NADV. The NADV resulting from link layer address changes are unsolicited 
and the ones resulting from the DAD are solicited.

But that is not really the issue here.
A node connected through a validating port should not be able to send a 
NADV for an address for wich it has no binding. If the host actually 
owns the source address, then a binding should exist

> What is the default value for DEFAULT_LT?
not defined yet

> is for a global unicast address)
that would make sense, i guess

>   but what is this value for a
good question. Maybe we can make it infinity and only delete it when we 
need memory (delete basis on the address that has been unused for a 
longer period)

> Consequences: H1 and H2 will own the same IP address (and H1 will no
i see what you mean. let me think about this a bit further

> I assume that the different cases are the ones described below. Correct?
no, thsi is a different case. This is actually the optimistic DAD case, 
where the host start sending packet right after sending the DAD NSOL. If 
we want to support optimistic DAD we should forward the packets (or at 
least store them for a while and then forward them). If we want to make 
sure that no hosts ever sends packet with a spoofed address, then we 
should discard the packets
That is why this is left open (*)

> s/the state is/The state is
done

> received through a Validating port equal to P?
this is what we discussed above. see (*)

> address at the same time (i.e. a DAD_NSOL is received on a
right
this case is likely to not have a very good solution, since the FCFS 
ownership principle doesn't help you, right?
Hopefully, this will not occur thanks to the random delay that is 
intrduced for DAD

> Lifetime is infinite, that should not work ... :(
right
As i mentioned, this is only a problem when you run out of memory in the 
device. At that point, you may want to start deleting and use a samrt 
algorithm for the deletion, such as the entry that has been unused for 
longer plus some probes.

> What is the default value for TENT_LT?
not defined yet, suggestions?

> specific case I missed, I would suggest to keep the STATE to
ok

> s/the LAYER_2 ANCHOR set to P'/the LAYER_2 ANCHOR is modified from P to P'
ok

> Same comment as for TESTING_TP case
ok

> Solicited Node Multicast group for all the potential addresses?
but the savi device would only do that for addresses that belong to 
hosts for which this savi device is the first SAVI device their traffic 
encounters.
In other words, these DAD NSOL will not be relayed by other switches, 
but will reach the SACVI device in any case, agree?

Thanks, marcelo

> 2010/5/13<[email-masked]>:
>