Re: Some definitions (Was: Re: New issue 16: No packets from other end?)

 In your previous mail you wrote:

   Finally, what really matters for MOBIKE is an address pair, and
   whether communication using that address pair is possible. This
   is only possible if the two addresses are locally operational
   AND there's IP connectivity between them. The latter is what we
   are currently debating: do we expect the connectivity to be
   tested and the best pair chosen by MOBIKE or something else?
   
=> IMHO the local choice should be done by a general module
and the role of the MOBIKE protocol is to inform the other peer.

   Details:
   
   1.  Available Addresses
   
       MOBIKE nodes need to be aware of what addresses they themselves have.

=> it seems you are in favor of the "set" style.

       If a node loses the address it is currently using for communications,
       another address must replace this address.

=> in the "set" style this another address MAY be known before.

       And if a node loses an
       address that the node's peer knows about, the peer must be informed.

=> IMHO this is one part (what I call "address management") of the
MOBIKE protocol.

       Similarly, when a node acquires a new address it may generally wish
       the peer to know about it.
   
=> more, it should wish the peer to accept it.

       Definition. Available address. An address is said to be available if
       the following conditions are fulfilled:
   
       o  The address has been assigned to an interface of the node.
   
       o  If the address is an IPv6 address, we additionally require that
          (a) the address is valid in the sense of RFC 2461, and that
          (b) the address is not tentative in the sense of RFC 2462.  In
          other words, the address assignment is complete so that
          communications can be started.
   
          Note this explicitly allows an address to be optimistic in the
          sense of [draft-ietf-ipv6-optimistic-dad] even though
          implementations are probably better off using other
          addresses as long as there is an alternative.
   
=> we can simply ask the address is usable for communication and
if we want to be strict we can ask the address is usable for IKEv2
communication (obviously when it is not the case we'll be in trouble).

       o  The address is a global unicast or unique site-local address
          [draft-ietf-ipv6-unique-local-addr].
   
=> I object: a link-local address should be available when the peer
is on the same link.

          That is, it is not an IPv6 link-local or site-local address.
          Where IPv4 is considered, it is not an RFC 1918 address.
   
=> I strongly object: a private address must be available when
the peer is in the same RFC 1918 "realm".

       Available addresses are discovered and monitored through mechanisms
       outside the scope of MOBIKE.

=> so the previous discussion doesn't make sense.

       These mechanisms include IPv6
       Neighbor Discovery and Address Autoconfiguration [RFC 2461-2462],
       DHCP [RFC 3315], enhanced network detection mechanisms detected by
       the DNA working group, and corresponding IPv4 mechanisms, such as
       [draft-ietf-dhc-dna-ipv4].
   
=> don't forget routing protocols when the node is a router (common
with SGs :-).

   2.  Locally Operational Addresses
   
       Definition.  Locally Operational Address.  An available address is
       said to be locally operational when its use is known to be possible
       locally: the interface is up and the relevant default router (if
       applicable) is known to be reachable.
   
=> this is too strict: the peer can be on the same link so reachable
without a default router.

       Locally operational addresses are discovered and monitored through
       mechanisms outside MOBIKE.  These mechanisms include IPv6 Neighbor
       Discovery [RFC 2461], corresponding IPv4 mechanisms, and link layer
       specific mechanisms.
   
=> don't forget source address selection (RFC 3484).

   3.  Operational Address Pairs
   
       The existence of locally operational addresses are not, however, a
       guarantee that communications can be established with the peer.  A
       failure in the routing infrastructure can prevent the sending of
       packets. For this reason we need the definition of a second level
       of granularity, for pairs addresses:
   
=> you are trying to reinvent RFC 3484...

       Definition.  Bidirectionally operational address pair.  A pair of
       locally operational addresses are said to be an operational address
       pair, iff bidirectional connectivity can be shown between the
       addresses.  That is, a packet sent with one of the addresses in the
       source field and the other in the destination field reaches the
       destination, and vice versa.
   
=> note this restricts MOBIKE to symmetrical connectivity.
IMHO this is a reasonnable constraint as IKEv2 requires it
(PS: does the constraint applies only to the IKE SA or
to both the IKE SA and the IPsec SA pairs?)

       Unfortunately, there are scenarios where bidirectionally operational
       address pairs do not exist.  For instance, ingress filtering or
       network failures may result in one address pair being operational in
       one direction while another one is operational from the other
       direction.  The following definition captures this general situation:
   
       Definition.  Undirectionally operational address pair.  A pair of
       locally operational addresses are said to be an unidirectionally
       operational address pair, iff packets sent with the first address as
       the source and the second address as the destination can be shown to
       reach the destination.
   
       Both types of operational pairs are discovered and monitored through
       the following mechanisms:
   
=> this is clearly outside the scope of MOBIKE IMHO!

       o  Positive feedback from upper layer protocols.  For instance, TCP
          can indicate to the IP layer that it is making progress.  This is
          similar to how IPv6 Neighbor Unreachability Detection can in some
          cases be avoided when upper layers provide information about
          bidirectional connectivity [RFC 2461].  In the case of unidirectional
          connectivity, the upper layer protocol responses come back using
          another address pair, but show that the messages sent using the
          first address pair have been received.
   
=> is IPsec an upper layer protocol for this?

       o  Explicit reachability tests.  For instance, the IKEv2 keepalive
          mechanism can be used to test that the current pair of addresses
          is operational.
   
=> this is an application layer positive feedback when what it is needed
is at the network layer.

       o  ICMP error messages.  Given the ease of spoofing ICMP messages,
          one should be careful to not trust these blindly, however.  One
          suggestion is to use ICMP error messages only as a hint to perform
          an explicit reachability test, but not as a reason to disrupt
          ongoing communications without other indications of problems.
   
=> I propose to use exactly what it was specified for transport
protocols like TCP which share the issue.

   4.  Primary Address Pair
   
       Contrary to SCTP which has a specific congestion avoidance design
       suitable for multi-homing, IP-layer solutions need to avoid sending
       packets concurrently over multiple paths; TCP behaves rather poorly
       in such circumstances.  For this reason it is necessary to choose a
       particular pair of addresses as the primary address pair which is
       used until problems occur, at least for the same session.
   
=> there is a simpler reason: the IKE SA uses *one* address pair.

       A primary address pair need not be operational at all times.  If
       there is no traffic to send, we may not know if the primary address
       pair is operational.  Neverthless, it makes sense to assume that the
       address pair that worked in some time ago continues to work for new
       communications as well.
   
=> communications? Perhaps you mean IKEv2 messages because other meanings
can be outside the scope of MOBIKE.

Regards

[email protected]

PS: if you remove every item outside of the scope of MOBIKE, you get
something very close to my "peer address management", don't you?