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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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/