D103 Terminology alignment
From: Jari Arkko
Subject: [Mobike] design draft issue: terminology alignment
Date: Wed, 21 Dec 2005 12:50:42 +0200
|
| Primary Path:
|
| The sequence of routers traversed by an IP packet that carries the
| default source and destination addresses is said to be the Primary
| Path. This definition is taken from [RFC2960] and adapted to the
| MOBIKE context.
The protocol draft uses the term "current path" (and so does
the latest version of the SHIM6 draft where the primary path
term was originally taken from).
Use the term "current path" instead here in Section 2 as well
as in the rest of the document.
| 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.
Peer address set is closer to what we want here?
(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?)
Also,
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| Those external hole punching mechanisms are beyond the scope of
Firewall pinhole opening is a better term, I think.
| One type of attack that needs to be taken care of in the MOBIKE
| protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec]
| and [Aur02] for more information about flooding attacks.
Called bombing attack earlier, and in the protocol draft.
From: Tero Kivinen
Subject: [Mobike] D103 design draft issue: terminology alignment
Date: Tue, 3 Jan 2006 18:04:01 +0200
Jari Arkko writes:
| |
| | Primary Path:
| The protocol draft uses the term "current path" (and so does
| the latest version of the SHIM6 draft where the primary path
| term was originally taken from).
|
| Use the term "current path" instead here in Section 2 as well
| as in the rest of the document.
Changed to use current instead of primary.
|
| | 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.
| 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.
| (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.
| | 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.
| | 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.
| | 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.
| | 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.
| | 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.
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.
| | 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.
| | Those external hole punching mechanisms are beyond the scope of
|
| Firewall pinhole opening is a better term, I think.
Changed.
| | One type of attack that needs to be taken care of in the MOBIKE
| | protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec]
| | and [Aur02] for more information about flooding attacks.
|
| Called bombing attack earlier, and in the protocol draft.
Changed.
From: Jari Arkko
Subject: Re: [Mobike] D103 design draft issue: terminology alignment
Date: Thu, 26 Jan 2006 15:29:47 +0200
| 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?
| 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 ...".
| 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?
| 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 see your problem. How about "the packet processing
module of the IPsec implementation"?
|| 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.
From: Tero Kivinen
Subject: Re: [Mobike] D103 design draft issue: terminology alignment
Date: Fri, 27 Jan 2006 15:23:12 +0200
| Right. Can we make this clearer in the design document?
...
| I understand. But you said "MOBIKE *protocol* should be
| able to perform ...".
I added text there "(not all of those are done explictly by the
current protocol)".
| Has that been made clear later in the document?
I do not think we explictly mention that we ignore responder
preferences, or that we assume that the initiator uses its own
preferences when selecting which address to use next. Do you think we
would really need that?
| I see your problem. How about "the packet processing
| module of the IPsec implementation"?
Done.
| 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.
I tought we decided that the protocol draft should be following the
design draft terminology, not the other way around. Actully in the
issue 29 of the protocol draft you said:
"Jari Arkko (2005-07-14):
My feeling is that, for practical reasons, we should try to
get rid of the term path, unless we use it in the route-included
sense. There are too many people that will complain when
they will see their favorite term misused :-)"
And then Pasi commented:
"Pasi Eronen (2005-07-14):
Well, it certainly seems so...
I've now changed those instances of "path" that don't really
consider the route to something else (but I've kept expressions
like "paths that contain NATs", "off-path", or "currently used
path has stopped working", which are more about the route
than just a pair of addresses). CHANGE_PATH notification was
renamed to UPDATE_SA_ADDRESSES."
I remember that we changed away from path in the desing draft around
same time, and then we started using terms like "IP address pairs" and
so on.
As the "connectivity tests" do not really care about the actual
routers on the path, so I do not think it should be called "path
tests":
"Pasi Eronen (2005-07-18):
Clarified some things, now avoids using the word "path" in senses that
don't really consider the route taken by the packets."
From: Jari Arkko
Subject: Re: [Mobike] D103 design draft issue: terminology alignment
Date: Fri, 27 Jan 2006 15:30:23 +0200
| I do not think we explictly mention that we ignore responder
| preferences, or that we assume that the initiator uses its own
| preferences when selecting which address to use next. Do you think we
| would really need that?
I think it is useful to point out the differences between
the abstract discussion you have in the design document
and the specific capabilities of the protocol as it turned
out to be. But I'll leave it you as the editor to worry
about the details...
...
Ah, now I see what your problem was. I still stand
by the earlier decisions about not using the word
path. But... the protocol document is done (approved
by IESG) and we're not editing it anymore unless
there's a major reason to do so.
My original issue was that the protocol spec calls
the testing function "path testing". So if we are
specifically referring that functionality then perhaps
we should use the same term. Otherwise lets use
a more appropriate term.
Oh well, I'm not sure this is easily fixable given no
edits to the protocol draft. I'll let you decide what
to do.
From: Tero Kivinen
Subject: Re: [Mobike] D103 design draft issue: terminology alignment
Date: Fri, 27 Jan 2006 15:52:14 +0200
| Oh well, I'm not sure this is easily fixable given no
| edits to the protocol draft. I'll let you decide what
| to do.
I think we now use "connectivity test" in the more abstract general
text and then we do use "path test" when we talk about the exact
implementation issues on the protocol, so I do not think we have
problem here.