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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sat, 07 March 2020 16:56 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF98E3A1625 for <dmm@ietfa.amsl.com>; Sat, 7 Mar 2020 08:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCdIF8js1pIN for <dmm@ietfa.amsl.com>; Sat, 7 Mar 2020 08:56:19 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7951C3A161F for <dmm@ietf.org>; Sat, 7 Mar 2020 08:56:18 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id a13so6532640edu.7 for <dmm@ietf.org>; Sat, 07 Mar 2020 08:56:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5f2HqVXki9UnzhAsIYhn0hM5zVBOzEMndN813NY9IV4=; b=FYUiFWsAEn2sEqKq388bITBZX1pbHTCCkBo3nB13BhYFrfRhqyRzIeon6nE1mU6ICt FvyT4uqKSF8Hc14oUvdqD148Q52KSSMOUekVXz6wa0fLJFuyd9s8iqgwUWnCL4UpX8kl RDd0DrgZGyC1xmI1R0AbxK6TjRc6lz9qNnzKpD/hOwk9hLrJlEAY/Ot9qZVp3EMnzCzz iFgWPEF2tKrje12+z3j5dt2hd59kPAx/gagsmN5EL2yMuhJPz8w0Eig5Ry1CLGCPXDG+ DdU4aRhpYDegugaKXnD2wNAREIB0MaeDvztJQFTE7KavnFiE/UMgIQ8dkgB12FlQDONe LT5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5f2HqVXki9UnzhAsIYhn0hM5zVBOzEMndN813NY9IV4=; b=lh8IazwOda7cL3imEBq6jjZSG5B9Sm3/45JoJjwocG4gXEGcbM81arJrUOqnIWu0LV Ua9tBebdEAz432r/yOG3aO0EfycTBOsdgtTzFh99PwIJdYAPRewB08Z4WP6DbmIi2kKi da+1MU3KmR8dsjw0rL34JmhePorx4aKPH1WppekZLiQfMwtpnTjDB/nED1kWrcqJY4Yg EubwMsS6s688bnsiIAyEMN2evOqiaAUlrGDbRgxHoi+MszVEjxNQgRb4lWZRNej6mIRr yspVqxbYK4xSH5AgdRghMaUGbIraXxFYeuM1iL37UPN81ezWnqCsfRzZ8FY4JMgXYYx+ 8CgA==
X-Gm-Message-State: ANhLgQ1xjJyOYI2dIUFyxivd+mNXI5hhwKD77rbpdg4A7ADWC/C2Yh8O 1ZxIs4Z7+NEUQXFuYm9WUVcNmNHbjKsmCS8f/c2phQ==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vs8RauE/2gpBcW+W/58h8fEanTF2492kuek+M65?= =?utf-8?q?LoqevXtsSiX8Q418mYF/0aLcCTmTLG9fwy92YvTMQUaEZhc=3D?=
X-Received: by 2002:a17:906:ca53:: with SMTP id jx19mr8045004ejb.192.1583600176373; Sat, 07 Mar 2020 08:56:16 -0800 (PST)
MIME-Version: 1.0
References: <158337360559.29429.15629947241139453126@ietfa.amsl.com>
In-Reply-To: <158337360559.29429.15629947241139453126@ietfa.amsl.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sat, 7 Mar 2020 17:55:59 +0100
Message-ID: <CALypLp9TCb6_XFW120SaUxGXSwAmSHjMA0kw+zH0hz-6f76=kQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dmm-distributed-mobility-anchoring@ietf.org, dmm-chairs <dmm-chairs@ietf.org>, dmm <dmm@ietf.org>, Dapeng Liu <maxpassion@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000facc9e05a046a51e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/zzh3iyLmr7dFmV1GdWEZwyvFxNQ>
Subject: Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-distributed-mobility-anchoring-14: (with DISCUSS and COMMENT)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Mar 2020 16:56:22 -0000
X-List-Received-Date: Sat, 07 Mar 2020 16:56:22 -0000

Hi Benjamin,

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

On Thu, Mar 5, 2020 at 3:00 AM Benjamin Kaduk via Datatracker <
noreply@ietf.org> wrote:

> 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.
>

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


>
> 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).
>

[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
> IPsec and IKEv2 usage.
>

[CB] Thanks. Added.


>
>
> ----------------------------------------------------------------------
> 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?
>
>
[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
>
>    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?
>
>
[CB] I agree it's probably better to just use "route". We have changed this
in version -15 (to be submitted soon).


>       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?
>

[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.


>
>       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/?
>

[CB] Right, thanks.


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

[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.


>
> 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?
>

[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.


>    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.)
>

[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.


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

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


>
>    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?
>

[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."


>
>    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!
>

[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.


> 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?
>

[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."


>
>    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.
>

[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.


>
> 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]
>

[CB] Same resolution as before.


>
>    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.
>

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

>
>    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.
>

[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.


>
>    [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)?
>

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


>
>    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?
>

[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.


>
> Section 5
>
>    As stated in [RFC7333], "a DMM solution MUST supportany security
>
> nit: s/supportany/support any/
>

[CB] Fixed, thanks.

Thanks again for all the good comments.

Carlos