Subject: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 04 Mar 2020 18:00:05 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dmm-distributed-mobility-anchoring-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for discussing the need to secure the various control-plane
interactions as part of the Security Considerations.  In addition to the
integrity and source-authentication properties already mentioned, we
need to say that the control-plane functionality will apply
authorization checks to any commands or updates that are made by the
control-plane protocol.

Similarly, I didn't see any discussion of authorization for applying or
making changes to the "rules" that are mentioned as needing to be
applied by a data-plane node (as mentioned in the COMMENT where I ask
for clarification on the nature of such rules).

Also, we should reference RFCs 8221 and 8247 for the current guidance on
IPsec and IKEv2 usage.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

While I see the value in having this document to crystallize thinking
about the various mobility anchoring techniques that are possible, it's
not clear to me how much archival value this document would add to the
RFC series in the absence of specific protocol mechanisms to implement
the functionality described therein.  As such, I expect to change my
ballot position to Abstain after my Discuss points are resolved.

Section 1

   When the MN wants to continue using its assigned prefix to complete
   ongoing data sessions after it has moved to a new network, the
   network needs to provide support for the MN's IP address -- and

The new network, right?

Section 2

   Anchoring (of an IP prefix/address):  An IP prefix, i.e., Home
      Network Prefix (HNP), or address, i.e., HoA, assigned for use by
      an MN is topologically anchored to an anchor node when the anchor
      node is able to advertise a connected route into the routing

Is "connected route" a term of art I should be looking up?

      and manages the network location information of an MN.  The
      location information may be a binding of the advertised IP
      address/prefix, e.g., HoA or HNP, to the IP routing address of the
      MN or of a node that can forward packets destined to the MN.

I assume this ("may be [...] or") is not intended to be an exhaustive
list?

      In a client-server protocol model, location query and update
      messages may be exchanged between a Location Management client
      (LMc) and a Location Management server (LMs), where the location
      information can be updated to or queried from the LMc.

nit: s/updated to/updated from/?

Do we want to discuss the authentication/authorization for such location
management functions here?  (Including both MN/LMc and LMc/LMs
interactions.)

Section 4

   There may be multiple IP prefixes/addresses that an MN can select
   when initiating a flow.  They may be from the same access network or
   different access networks.  The network may advertise these prefixes
   with cost options [I-D.mccann-dmm-prefixcost] so that the mobile node
   may choose the one with the least cost.  In addition, these IP

This draft has not been updated since 2016.  Is it still expected to
progress, such that a reference to it remains valuable?

   prefixes/addresses may be of different types regarding whether
   mobility support is needed [RFC8653].  A MN will need to choose which
   IP prefix/address to use for each flow according to whether it needs
   IP mobility support or not, using for example the mechanisms
   described in [RFC8653].

I'm confused.  "these prefixes/addresses" seems to refer to the ones
advertised by the network, but the question of whether mobility support
is needed seems like a matter local to the MN and not a need of the
network.  (Perhaps the network might *provide* different mobility
services for different prefixes/addresses, but that's not what this text
currently says.)

Section 4.1

I suggest to expand access router or list it in the terminology section.

   When IP session continuity is needed, even if a flow is ongoing as
   the MN moves, it may still be desirable for the flow to change to
   using the new IP prefix configured in the new network.  The flow may
   then close and then restart using a new IP address configured in the
   new network.  Such a change in the IP address of the flow may be

It's perhaps a little confusing, in a rhetorical sense, to talk about
"the flow changing to use the new prefix" but doing that by having the
flow "close and then restart" -- is it really the same flow after it has
closed?

   Note that in this scenarios, if there is no mobility support provided
   by L4 or above, an application might be able to stop before changing
   point of attachement, and therefore the traffic would stop.

I'm not sure what "might be able to stop" is intended to mean.
Regardless, it's quite clear that the traffic will stop upon the
mobility event in this scenario, since the network does not provide
continuity services!

Section 4.2

   prefix.  The latter enables optimized routes but requires some data
   plane node that enforces rules for traffic indirection.  Next, we

I'm not sure I understand the role this rule-enforcment is meant to
play.  What sort of rules would it be enforcing?

   to AR1 per default routing).  The LM and FM functions are implemented
   as shown in Figure 6.

Where is FM indicated in Figure 6?  I cannot find it.

Also, should there be any control-plane anchoring indicated in Figure 6?

Section 4.3

   We focus next on the case where the mobility anchor (data plane
   function) is changed but binds the MN's transferred IP address/
   prefix.  This enables optimized routes but requires some data plane
   node that enforces rules for traffic indirection.

[same question as above about the rules]

   IP mobility is invoked to enable IP session continuity for an ongoing
   flow as the MN moves to a new network.  Here the anchoring of the IP
   address of the flow is in the home network of the flow (i.e.,
   different from the current network of attachment).  A centralized

nit(?): this usage of "here" is surprising, in that it seems to discuss
the same case as the previous section, and not the new mechanism that
we're describing in this section.

   The IP prefix/address anchoring may move without changing the IP
   prefix/address of the flow.  Here the LM and FM functions in Figure 1
   in Section 3.1 are implemented as shown in Figure 7.

Where is the FM function indicated in Figure 7?  I cannot find it.

   [I-D.ietf-rtgwg-atn-bgp].  When a mobile associates with an anchor
   the anchor injects the mobile's prefix into the global routing
   system.  If the mobile moves to a new anchor, the old anchor

nit: "mobile node" or just "MN" (twice)?

   withdraws the /64 and the new anchor injects it instead.

What kind of synchronization and/or serialization is needed between the
withdrawl and injection of the /64 in question?

Section 5

   As stated in [RFC7333], "a DMM solution MUST supportany security

nit: s/supportany/support any/

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sat, 7 Mar 2020 17:55:59 +0100

Hi Benjamin,

Thanks a lot for your comments. Please find below my answers.

> https://datatracker.ietf.org/doc/draft-ietf-dmm-distributed-mobility-anchoring/

[CB] Thanks. I've added that to version -15 (to be submitted soon).

> for clarification on the nature of such rules).

[CB] Thanks. Even though we have changed a bit the writing to avoid the
term "rule", we have added some text regarding the use of authentication
and authorization mechanisms when doing traffic indirection  in version -15.

> Also, we should reference RFCs 8221 and 8247 for the current guidance on

[CB] Thanks. Added.

[CB] The new network and the old one, understanding "old" by the one
anchoring the prefix used by the MN. That's why we just use the generic
term "network" without prepending "new".

Section 2
> Is "connected route" a term of art I should be looking up?
[CB] I agree it's probably better to just use "route". We have changed this
in version -15 (to be submitted soon).

> I assume this ("may be [...] or") is not intended to be an exhaustive

[CB] Right. Though the cases listed are the ones I can think of now as
making sense. But we don't want to close the door for other options that
might also work there.

> nit: s/updated to/updated from/?

[CB] Right, thanks.

> management functions here?  (Including both MN/LMc and LMc/LMs

[CB] I've added "secure (i.e., authenticated and authorized)" before
"location query and update messages may be
exchanged between [...]" to make it clear that of course these signalling
needs to be properly secured. I think going into more details there will
deviate the focus from the main point of this document. Anyway, the
security considerations section should cover all these parts as well.

> progress, such that a reference to it remains valuable?

[CB] We use this reference as an example of approach. There are other
examples that we could reference, but I wanted to give the credit to the
guys that I think first proposed this. That's why I kept the reference, but
I can very easily replace it with another one if you think it would be
best.

> services for different prefixes/addresses, but that's not what this text

[CB] The prefixes/addresses refer to the one provided by the network. The
question of whether the MN needs mobility or not is local to the MN, but if
the MN actually need it, support from the network might be needed
(depending on the type of mobility support of the MN and network). I've
reworded it to:

"In addition, the IP prefixes/addresses provided by the network may be of
different types regarding whether mobility support is supported [RFC 8653]
."

I hope now the text is clearer.

> I suggest to expand access router or list it in the terminology section.

[CB] Done (expanded first time it appears in the text).

> flow "close and then restart" -- is it really the same flow after it has

[CB] You are right. If we are picky with the terminology, the flow is
indeed different. I've reworded to use "application flow" instead of
"flow". Hope this is a bit better. Current text (some other small changes
performed) read as follows:

"When IP session continuity is needed, even if an application flow is
ongoing as
the MN moves, it may still be desirable for the application flow to change
to
using the new IP prefix configured in the new network. The application flow
may
then be closed at IP level and then be restarted using a new IP address
configured in the new network. Such a change in the IP address used by the
application flow may be enabled using a higher layer mobility support which
is
not in the scope of this document."

> mobility event in this scenario, since the network does not provide

[CB] That sentence was definitely not good. I've just simplified it to:

"Note that in these scenarios, if there is no mobility support provided by
L4 or
above, application traffic would stop."

which is kind of clear, but I think it doesn't harm keeping it.

> play.  What sort of rules would it be enforcing?

[CB] We mean routing updates that enable the anchor mobility. I probably
used the term "rules" because one example of approach to use in a local
domain is OpenFlow. I've reworded it to the following:

"The latter enables optimized routes but requires some data plane node that
enforces
traffic indirection."

> Where is FM indicated in Figure 6?  I cannot find it.

[CB] Ooops. Thanks. Fixed!

> Also, should there be any control-plane anchoring indicated in Figure 6?

[CB] There is the LM part indicated in AR2.

> [same question as above about the rules]

[CB] Same resolution as before.

> we're describing in this section.

[CB] OK, I've removed "here".

> Where is the FM function indicated in Figure 7?  I cannot find it.

[CB] FM is not involved here. I've fixed the text. When we wrote the text I
was thinking on a generic way of referring to LM and FM functions, not
implying that they need to be implemented in all the cases. But I agree it
is not very clear.

> nit: "mobile node" or just "MN" (twice)?

[CB] Probably better to use MN. I've fixed it.

> withdrawl and injection of the /64 in question?

[CB] That'd be part of the control plane signalling, which would depend on
the actual solution being used. Since this document does not go into the
specifics of an actual solution, we don't go further.

> nit: s/supportany/support any/

[CB] Fixed, thanks.

Thanks again for all the good comments.

Carlos

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Mar 2020 15:39:34 -0700

Hi Carlos,

Sorry for the slow reply; it's been a crazy couple weeks.

> > Also, we should reference RFCs 8221 and 8247 for the current guidance on

Thanks!
I think the current placement of these references in the -15 make it sound
like they are references for IPsec and IKEv2 respectively, and not "just"
the best-practices for configuring them.  Just moving the references later
in the sentences would probably help, though I'd recommend adding another
sentence "The current guidance for IPsec and IKEv2 usage is given in
[RFC8221] and [RFC8247], respectively" to be fully clear about why they are
being referenced.

That said, I'm going to change my ballot position to No Objection after I
send this mail, so no need to check back on the precise wording.

> term "network" without prepending "new".

Ah, I see now; thanks.

> making sense. But we don't want to close the door for other options that

Sometimes a list of two options like this can be misread as intended to be
exhaustive, in which case a phrase like "may be (for example)" can help, or
adding some generic catch-all clause to the end of the list.

> security considerations section should cover all these parts as well.

Sounds good, thanks.

> I can very easily replace it with another one if you think it would be

My personal preference for picking references is biased towards referencing
documents that can be used to build deployable solutions, but I see no flaw
in your reasoning here.

> I hope now the text is clearer.

I think so, thanks.

> not in the scope of this document."

Thank you!

> specifics of an actual solution, we don't go further.

Hmm, okay.

> Thanks again for all the good comments.

And thanks for the updates!

-Ben

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Wed, 18 Mar 2020 10:25:44 +0100

Thanks a lot Benjamin!

We'll implement your wording suggestions in the next revision!

Carlos

On Tue, Mar 17, 2020 at 11:39 PM Benjamin Kaduk <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html