Re: D103 design draft issue: terminology alignment

Tero Kivinen wrote:

>  
>
>>>   Preferred Address:
>>>
>>>      The IP address of a peer to which MOBIKE and IPsec traffic should
>>>      be sent by default.  A given peer has only one active preferred
>>>      address at a given point in time, except for the small time period
>>>      where it switches from an old to a new preferred address.  This
>>>      definition is taken from [I-D.ietf-hip-mm] and adapted to the
>>>      MOBIKE context.
>>>      
>>>
>>The protocol draft does not use this term.
>>    
>>
>
>True, but design document do use this term when describing different
>options we had. This document is not only describing what we have in
>the protocol document (the protocol document does that), this also
>describes why and how we ended up there. 
>  
>
Ah, I see now. OK.

>>Peer address set is closer to what we want here?
>>    
>>
>
>No peer address set is the set of all addresses, and preferred address
>is the one address the other end preferred to be used. If we have only
>one address pair in use (as we have with initiator decides option)
>then the preferred addresses and current addresses are mostly same.
>  
>
Ok, I think.

>>(Also, I'm not sure the protocol we have actually communicates
>>the address preferences. The initiator makes a decision, but
>>does the ordering in an address update indicate preference?)
>>    
>>
>
>In current protocolwe do not communicate that, but we did consider
>options where we did communicate those, and we do describe those in
>the document, and then we say we ended up using initiator decides. 
>  
>
Right. Can we make this clearer in the design document?

>>>   The MOBIKE protocol should be able to perform the following
>>>   operations:
>>>
>>>   o  Inform the other peer about the peer address set
>>>
>>>   o  Inform the other peer about the preferred address
>>>
>>>   o  Test connectivity along a path and thereby to detect an outage
>>>      situation
>>>
>>>   o  Change the preferred address
>>>      
>>>
>>Again, not sure we actually communicate the preferred
>>information -- but I may be missing something.
>>    
>>
>
>In initiator decides the preferred information is not needed to be
>communicated that much, as initiator decides... the initiator simply
>needs to know his own preferences and use those, as he is the one
>making decisions. Again in other options we would need that
>information. 
>  
>
I understand. But you said "MOBIKE *protocol* should be
able to perform ...".

>>>   Another MOBIKE usage scenario is depicted in Figure 2.  In this
>>>   scenario, the MOBIKE peers are equipped with multiple interfaces (and
>>>   multiple IP addresses).  Peer A has two interface cards with two IP
>>>   addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1
>>>   and IP_B2.  Each peer selects one of its IP addresses as the
>>>   preferred address which is used for subsequent communication.
>>>   Various reasons (e.g., hardware or network link failures), may
>>>   require a peer to switch from one interface to another.
>>>      
>>>
>>Is this in line with what the protocol draft does?
>>    
>>
>
>No, and it does not try to be aligned. We are describing generic
>scenario, the actual protocol work differs from this generic scenario,
>and we do not fully support this in the protocol we selected. As in
>our case the initiator decides the preferences then the responders
>preferences are ignored in our protocol. 
>  
>
Has that been made clear later in the document?

>>>   Operational address pair:
>>>
>>>      A pair of operational addresses are said to be an operational
>>>      address pair, if and only if bidirectional connectivity can be
>>>      shown between the two addresses.  Note that sometimes it is
>>>      necessary to consider connectivity on a per-flow level between two
>>>      endpoints.  This differentiation might be necessary to address
>>>      certain Network Address Translation types or specific firewalls.
>>>      This definition is taken from [I-D.arkko-multi6dt-failure-
>>>      detection] and adapted for the MOBIKE context.  Although it is
>>>      possible to further differentiate unidirectional and bidirectional
>>>      operational address pairs, only bidirectional connectivity is
>>>      relevant to this document and unidirectional connectivity is out
>>>      of scope.
>>>      
>>>
>>(snip)
>>
>>    
>>
>>>   Bidirectional Address Pair::
>>>
>>>      The address pair, where traffic can be sent to the both
>>>      directions, simply by reversing the IP addresses.  Note, that the
>>>      path of the packets going to each direction might be different.
>>>
>>>   Unidirectional Address Pair::
>>>
>>>      The address pair, where traffic can only be sent in one direction,
>>>      and reversing the IP addresses and sending reply back does not
>>>      work.
>>>      
>>>
>>The explanation of directionality on the first definition
>>seems superfluous.
>>    
>>
>
>Mostly leftovers from the time when we didn't have bidirectional /
>unidirectional address pairs defined here at all.
>
>On the other hand, I do not think the extra text there does any harm,
>and might actually make it easier to understand what operational
>address pair is. I do hate terms refering to other terms refering to
>other terms where you need to parse through several definations of the
>terms before you can find out what the term actually means. 
>  
>
Ok.

>  
>
>>>   Figure 1 shows a break-before-make mobility scenario where a mobile
>>>   node changes its point of network attachment.  Prior to the change,
>>>   the mobile node had established an IPsec connection with a security
>>>   gateway which offered, for example, access to a corporate network.
>>>   The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took
>>>   place over the path labeled as 'old path'.  The involved packets
>>>   carried the MN's "old" IP address and were forwarded by the "old"
>>>   access router (OAR) to the security gateway (GW).
>>>      
>>>
>>Consider talking only about routers, not access routers.
>>    
>>
>
>I actually think access router is better, as we are not talking about
>routers in the general, we are talking about the closest router
>providing us the access to the internet.
>  
>
Ok.

>  
>
>>>   MOBIKE interacts with the IPsec engine using for
>>>   example the PF_KEY API [RFC2367].  Using this API, the MOBIKE daemon
>>>   can create entries in the Security Association (SAD) and Security
>>>   Policy Databases (SPD).  The IPsec engine may also interact with
>>>   IKEv2 and MOBIKE daemon using this API.
>>>      
>>>
>>"IPsec engine" is a term that exists in RFC2401, I think. Use
>>"IPsec implementation" or some other term.
>>    
>>
>
>Nope. IPsec engine is not defined in the RFC 2401 or in the RFC 4301.
>  
>
Right, that was my complaint, but my e-mail missed the
word "not" :-)

>I have normally used IPsec engine to refer to the "kernel" side of the
>IPsec implementation, i.e. things related to the actual packets, SAD,
>and partly SPD too (i.e. those parts of SPD which are not related to
>the IKE or policy management).
>
>IPsec implementation is bit wrong, as MOBIKE can be considered as part
>of IPsec implementation too... as it is IKEv2 extension and IKEv2 is
>part of IPsec implementation (i.e. part of the IPsec architecture
>defined in RFC 4301).
>
>If you have better term to use than IPsec engine, I can switch to
>that, but I myself cannot think one now. 
>  
>
I see your problem. How about "the packet processing
module of the IPsec implementation"?

>>>   In order to address certain failure
>>>   cases, MOBIKE should perform connectivity tests between the peers
>>>   (potentially over a number of different paths).
>>>      
>>>
>>I think they are called "path tests" in the protocol draft.
>>    
>>
>
>I think path tests is bad name, as we are not testing paths, we are
>testing connectivity between two addresses. 
>  
>
Perhaps, but we are not debating the name -- what I'm
saying is that you should align the terminology with the
protocol draft (even if you might think that the term in
the protocol draft was wrong). Otherwise it'll be confusing.

--Jari