Hi Carlos, Also inline (but not much left to say!)
On Sun, Mar 08, 2020 at 06:58:14PM +0100, CARLOS JESUS BERNARDOS CANO wrote: > Hi Benjamin, > > Thanks a lot for another very good review. Please find my comments inline > below. > > On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker < > [email protected]> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dmm-pmipv6-dlif-05: 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-pmipv6-dlif/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I have a very boring Discuss point and a somewhat boring point, and > > expect to change my ballot to Yes once they're resolved. > > > > In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid > > bursts when the CMD is fanning out PBUs, but in Section 6 we say that > > pacing "SHOULD" be used; please resolve the inconsistency (preferrably > > with "MUST" as Mirja requests). > > > > [CB] Done in version -06 (to be submitted soon). > > > > > > Please also include some discussion of privacy considerations (I give > > some suggestions in the COMMENT). > > > > [CB] OK, I'll do. > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this well-written document! It is clearly written, and when > > multiple approaches exist, does well at laying out the different options > > and their pros/cons, as befits an Experimental document. Also, several > > times I have started to write a comment only to realize that it is > > answered by the following text :) > > > > [CB] Thanks, very much appreciated. > > > > > > Section 1 > > > > The Distributed Mobility Management (DMM) paradigm aims at minimizing > > the impact of currently standardized mobility management solutions > > which are centralized (at least to a considerable extent). > > > > I'd consider saying a little more about which aspects of their operation > > are centralized. Perhaps the following paragraph suffices, though. > > > > [CB] I've added another reference to RFC 7333, where this is explained in > detail. As you mention below, we go a bit into these aspects of centralized > operation in the following paragraph, and I personally believe it is better > not to add too much text on this aspect (which is covered by RFC 7333). > Please, let me know if you are not happy with this resolution. > > > > > > Following this idea, in our proposal, the central anchor is moved to > > the edge of the network, being deployed in the default gateway of the > > mobile node. That is, the first elements that provide IP > > > > (side note: Using the singular "central anchor" poses an interesting > > rhetorical question: is the (formerly) single central anchor being > > duplicated and spread amongst all access routers, or does there remain a > > single central anchor (per MN), just one that moves around along with > > the MN.) > > > > [CB] The whole idea of the DMM approach specified in this document is that > we move from a "single central anchor" to a "multiple distributed anchors". > Note that the specified approach allows for a central anchor to be still > present (and used by an MN for communications where it is more > appropriate), but this is more an operational decision (probably more in > scope of RFC 8653). > > > > > > anchors to retrieve the MN's previous location(s). Also, a key- > > aspect of network-based DMM, is that a prefix pool belongs > > exclusively to each MAAR, in the sense that those prefixes are > > assigned by the MAAR to the MNs attached to it, and they are routable > > at that MAAR. > > > > It might be worth some statement relating this "ownership" of prefixes > > to actual mobility events -- e.g., they are assigned to MNs attached to > > it at that time, but remain with those MNs as mobility occurs, but > > always remain routable at that MAAR as well as towards the MN itself. > > > > [CB] OK, I've added a sentence adopting part of your text. Thanks. > > > > We consider partially distributed schemes, where the data plane only > > is distributed among access routers similar to MAGs, whereas the > > > > nit: I suggest s/the data plane only/only the data plane/ > > > > [CB] OK, thanks. > > > > > > control plane is kept centralized towards a cardinal node used as > > information store, but relieved from any route management and MN's > > data forwarding task. > > > > What's the scope of "single" here -- per deployment, per prefix, per > > MAAR, ...? > > > > [CB] Sorry, I don't get this comment. I don't see "single" mentioned in the > quoted textl Sorry! I was assuming that the "cardinal node" was a single centralized information store, and that's the "single" I was trying to ask about. Re-reading, I would assume that this "cardinal node" is per deployment, so it may not be worth changing the text if that's in fact the case. > > > > > P-MAAR (Previous MAAR). When a MN moves to a new point of attachment > > a new MAAR might be allocated as its anchor point for future IPv6 > > prefixes. The MAAR that served the MN prior to new attachment > > becomes the P-MAAR. It is still the anchor point for the IPv6 > > prefixes it had allocated to the MN in the past and serves as the > > > > (side note? Do we expect those previous allocations to eventually "time > > out" as sessions using them terminate? Or are the allocations more > > permanent, with intent to reuse if/when the MN returns to that MAAR?) > > > > [CB] The expectation is that previous allocations will eventually time-out > as sessions using them terminate. > > > > > > Section 3 > > > > interest and eventually take the appropriate action. The procedure > > adopted for the query and the messages exchange sequence might vary > > to optimize the update latency and/or the signaling overhead. Here > > > > nit: wrong pluralization in "messages exchange sequence" > > > > [CB] OK, fixed. > > > > > > Section 3.1 > > > > 3. Since this is an initial registration, the CMD stores a permanent > > BCE containing as primary fields the MN-ID, Pref1 and MAAR1's > > address as a Proxy-CoA. > > > > [how permanent is "permanent"?] > > > > [CB] I've removed "permanent" as it is not really needed. The BCE stays at > the CMD until the session is de-registered (it is "more permanent" that the > BCEs at the P-MAARs). > > > > > > Section 3.2 > > > > 1. When the MN moves from its current point of attachment and > > attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6 > > prefix (Pref2), it stores a temporary BCE, and it sends a plain > > PBU to the CMD for registration. > > > > It's not clear to me at this point how MAAR2 has enough information to > > determine that this will be a "plain" PBU vs. the the PBU used for > > initial registration. (That said, it's also not clear to me that the > > send PBU actually differs on the wire, so maybe this is just a > > rhetorical question. Er, a question of rhetoric, that is.) > > > > [CB] They are actually the same PBUs, as MAAR2 does not know at that point > if the MN had been already registered. Both PBUs would be "plain". I've > removed "plain" and "another" to make it clearer. > > > > > > 4. The CMD, after receiving the PBA, updates the BCE populating an > > instance of the P-MAAR list. The P-MAAR list is an additional > > field on the BCE that contains an element for each P-MAAR > > involved in the MN's mobility session. The list element contains > > the P-MAAR's global address and the prefix it has delegated (see > > Appendix B for further details). Also, the CMD sends a PBA to > > the new S-MAAR, containing the previous Proxy-CoA and the prefix > > anchored to it embedded into a new mobility option called > > Previous MAAR Option (defined in Section 4.5), so that, upon PBA > > arrival, a bi-directional tunnel can be established between the > > two MAARs and new routes are set appropriately to recover the IP > > flow(s) carrying Pref1. > > > > To check my understanding: there will only be one Previous MAAR Option > > present and it will describe only a single MAAR, which implies that if > > there are multiple P-MAARs, traffic directed to an arbitrary prefix > > based at one of them is expected to traverse multiple tunnels from > > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN? > > [Hmm, looks like my understanding is wrong. I'd consider making > > "previous Proxy-CoA" and "the prefix anchored to it" plural to give the > > reader a hint as to what's coming, though I can understand if there is > > desire to keep the initial mobility example simple and only gradually > > introduce the complexity in question.] > > > > [CB] I've been looking at it and changing it back and forth several times. > I prefer to keep the initial mobility example. Just to answer your > question, in general there might be multiple options. This is what the text > you point below should indicate (among other things). > > > > For MN's next movements the process is repeated except the number of > > P-MAARs involved increases (accordingly to the number of prefixes > > that the MN wishes to maintain). Indeed, once the CMD receives the > > first PBU from the new S-MAAR, it forwards copies of the PBU to all > > the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR > > prior to handover) and in the P-MAARs list. They reply with a PBA to > > the CMD, which aggregates them into a single one to notify the > > S-MAAR, that finally can establish the tunnels with the P-MAARs. > > > > I'm not sure I understand the cardinality of P-CoA -- is it one, > > the single S-MAAR prior to handover, or many, all P-MAARs in the list? > > > > [CB] There are multiple P-CoAs, but current writing might lead to think > there is only one. One P-CoA is the one listed in the BCE (the one of the > previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I've > rewritten a bit the text trying to make this clearer: "Indeed, once the CMD > receives the first PBU from the new S-MAAR, it forwards copies of the PBU > to all the P-MAARs indicated in the BCE, namely the one registered as > current P-CoA (i.e., the MAAR prior to handover) plus the ones in the > P-MAARs list." Thanks, this helps a lot! > > > When there are multiple previous MAARs, e.g., k MAARs, a single PBU > > received by the CMD triggers k outgoing packets from a single > > incoming packet. This may lead to packet bursts originated from the > > CMD, albeit to different targets. Pacing mechanisms MAY be > > introduced to avoid bursts on the outgoing link. > > > > I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable > > than "MAY" to me, here. > > > > [CB] Actually, based on other comments we have decided to go for "MUST". Indeed. (It looks like I forgot to change this comment when I added a note to my discuss point after I read Mirja's position.) > > > Section 3.3 > > > > The handover latency experienced in the approach shown before can be > > reduced if the P-MAARs are allowed to signal directly their > > information to the new S-MAAR. This procedure reflects what was > > described in Section 3.2 up to the moment the P-MAAR receives the PBU > > with the P-MAAR option. At that point a P-MAAR is aware of the new > > > > nit(?): I think this is the S-MAAR option, not the P-MAAR option? > > > > [CB] Right! Thanks. > > > > > > S-MAAR including the prefix it is anchoring. This latter PBA does > > not need to include new options, as the prefix is embedded in the HNP > > option and the P-MAAR's address is taken from the message's source > > address. The CMD is relieved from forwarding the PBA to the S-MAAR, > > > > (side note: this assumes there's no NAT or tunneling or similar between > > MAARs, which seems like a plausible assumption, at least for now.) > > > > [CB] Yes, that's right. > > > > > > Section 3.4 > > > > side. When P-MAARs complete the update, they send a PBA to the CMD > > to indicate that the operation is concluded and the information is > > updated in all network nodes. This procedure is obtained from the > > > > Is there anything useful to say about behavior on timeout at the CMD > > (failing to reive a PBA from one or more P-MAARs)? > > > > [CB] A new Section 3.6 "Retransmissions and Rate Limiting" has been added > (to address also other received comments). I hope this addresses this > comment. It doesn't directly give guidance about the CMD's behavior as a recipient, but it does give some more context for the expected operation of the system, which should be enough. > > > Section 3.5 > > > > The de-registration mechanism devised for PMIPv6 cannot be used as is > > in this solution. The reason for this is that each MAAR handles an > > > > nit: s/as is/as-is/ > > > > [CB] Fixed, thanks. > > > > > > Indeed, when a previous MAAR initiates a de-registration procedure, > > because the MN is no longer present on the MAAR's access link, it > > removes the routing state for that (those) prefix(es), that would be > > deleted by the CMD as well, hence defeating any prefix continuity > > attempt. The simplest approach to overcome this limitation is to > > > > nit(?): s/when/if/. At least, this makes more sense to me if I do that > > ... maybe I'm just confused. > > > > [CB] OK, fixed. > > > > > > serving MAAR to de-register the whole MN session. This can be > > achieved by first removing any layer-2 detachment event, so that de- > > registration is triggered only when the session lifetime expires, > > > > I see that RFC 5213 has some mechanisms for lifetime management, but > > didn't get to look closely enough to understand how clear the necessary > > lifetime management will be in the DMM case when there are multiple > > prefixes registered to a given MN at different MAARs. (Also, 5213 > > doesn't seem to use the "session lifetime" phrase verbatim.) > > > > [CB] I've replaced "session lifetime" with "binding lifetime" to make it > more consistent with the terminology used in RFC 5213. Note that "mobility > session" is used in RFC 5213. Thanks! > > > > > Section 3.6 > > > > requiring special support from the mobile node's IP stack. This > > document defines the Distributed Logical Interface (DLIF), which is a > > software construct that allows to easily hide the change of > > associated anchors from the mobile node. > > > > A software construct in the MAAR, right? > > > > [CB] Yes, I've added "in the MAAR" to the text. > > > > > > > > How common is "HMAC" as an abbreviation for "hardware MAC address"? > > It's also an abbreviation for Hash-based Message Authentication Code, > > which confuses my poor security-focused brain, though I acknowledge that > > this does not necessarily extend to most of the target audience for this > > document... > > > > [CB] It is not common. To avoid potential confusions I've removed HMAC and > just used MAC, which I think it is sufficient in the scope of this document > (as we use LMAC for the logical one). > > > > and MN3, while MAAR2 is serving MN1. MN1, MN2 and MN3 have two > > P-MAARs: MAAR1 and MAAR2. Note that a serving MAAR always plays the > > > > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)? > > > > [CB] You are right. Here there was a mistake, as P-MAAR was being mixed > with anchoring MAAR. I've removed that sentence to keep it clearer. > > > > role of anchoring MAAR for the attached (served) MNs. Each MAAR has > > one single physical wireless interface. > > > > Have we defined "anchoring MAAR" yet? > > > > [CB] We have added a definition to the terminology section. > > > > Also, I assume that the "single physical interface" is just "as depicted > > in this example" and not a protocol requirement :) > > > > [CB] Yes, right. > > > > > > As introduced before, each MN always "sees" multiple logical routers > > -- one per P-MAAR -- independently of its currently serving MAAR. > > > > [same P-MAAR vs. S-MAAR split as above] > > > > [CB] Right, fixed by replacing P-MAAR with anchoring MAAR. > > > > > > > by the serving MAAR (MAAR2) configuring an additional distributed > > logical interface: mn1mar1, which behaves exactly as the logical > > interface configured by MAAR1 when MN1 was attached to it. This > > > > nit(?): "exactly" is asking for pedants to try and poke holes in the > > claimed perfection. > > > > [CB] Right, I removed "exactly". > > > > > > deprecated). The goal is to deprecate the prefixes delegated by > > these MAARs (which will be no longer serving the MN). Note that on- > > > > nit(?): s/which will be no longer/so that they will no longer be/, IIUC > > > > [CB] Fixed. > > > > > > Section 4.1 > > > > The intdir reviewer's comments regarding the flag bits seem apropos (I > > presume they were allocated by other extensions to 5213, but we should > > say something about it). > > > > [CB] OK, I'll address this in my response to the intdir review. It looks like the plan is to reference the IANA registry for the flags? That sounds good, though I assume it's still only in the editor's copy. > > > > > > > A new flag (D) is included in the Proxy Binding Update to indicate > > that the Proxy Binding Update is coming from a Mobility Anchor and > > > > "D" is for "DMM", I trust? It could be worth mentioning. > > > [CB] Yes, done. > > > > > > > > Is the D bit set for the PBUs sent from CMD to P-MAAR as well? > > > > [CB] Yes, I've fixed that. > > > > (I see that the PBA description uses a slightly different formulation to > > cover the 'D' bit; is there a reason to diverge?) > > > > [CB] No reason. I've updated the text to use the same formulation. > > > > > > Mobility Options > > > > Variable-length field of such length that the complete Mobility > > Header is an integer multiple of 8 octets long. This field > > contains zero or more TLV-encoded mobility options. The encoding > > and format of defined options are described in Section 6.2 of > > [RFC6275]. The MAAR MUST ignore and skip any options that it does > > not understand. > > > > MAARs that *receive* PBUs must be P-MAARs, right? > > > > [CB] Yes, but also a CMD. Therefore I've replaced "MAAR" with "receiving > node". > > > > Section 4.2 > > > > MAAR (D) > > > > The D is set to indicate that the sender of the message supports > > operating as a Mobility Anchor and Access Router. When a MAG that > > does not support the extensions described in this document > > receives a message with the D-Flag set, it MUST ignore the message > > and an error MUST be returned. > > > > Is the CMD considered a MAAR for this purpose? > > > > [CB] I've replaced "operating as a Mobility Anchor and Access Router" with > "operating as a MAAR or a CMD". > > > > contains zero or more TLV-encoded mobility options. The encoding > > and format of defined options are described in Section 6.2 of > > [RFC6275]. The MAAR MUST ignore and skip any options that it does > > not understand. > > > > What about the CMD? > > > > [CB] Same.. Therefore I've replaced "MAAR" with "receiving node". > > > > > > Section 4.3, 4.4 > > > > Prefix Length > > > > 8-bit unsigned integer indicating the prefix length of the IPv6 > > prefix contained in the option. > > > > Anchored Prefix > > > > A sixteen-byte field containing the mobile node's IPv6 Anchored > > Prefix. Only the first Prefix Length bytes are valid for the > > Anchored Prefix. The rest of the bytes MUST be ignored. > > > > Is the prefix length bits or bytes? > > > > [CB] Bits. Fixed (also mentioned by another review). > > > > > > Section 4.4 > > > > Is this also used to convey "local" prefixes in the PBA from CMD to > > S-MAAR? (If not, how does the S-MAAR know to advertise them from its > > DLIF?) > > > > [CB] Yes, this is right. I've rewritten the text to reflect it. > > > > > Section 4.5 > > > > What's the alignment requirement? > > (There's no need to put in a Reserved octet to keep things word > > aligned?) > > > > [CB] You are right. And this is embarrassing, as the internal code we use > is actually using the format with the extra reserved byte that was not > reflected in the document. > > > > Prefix Length > > > > 8-bit unsigned integer indicating the prefix length of the IPv6 > > prefix contained in the option. > > [...] > > Home Network Prefix > > > > A sixteen-byte field containing the mobile node's IPv6 Home > > Network Prefix. Only the first Prefix Length bytes are valid for > > the mobile node's IPv6 Home Network Prefix. The rest of the bytes > > MUST be ignored. > > > > [is the prefix length bits or bytes?] > > > > [CB] Bits. Fixed. > > > > > > Section 4.6 > > > > Is there an alignment requirement for this option? > > > > [CB] Yes, added. > > > > > > This new option is defined for use with the Proxy Binding Update and > > Proxy Binding Acknowledgement messages exchanged between the CMD and > > > > When is this option used in a PBA? > > > > [CB] Right, it is only used in a PBU. Fixed. > > > > > > Section 4.7 > > > > A new DLIF Link-local Address option is defined for use with the > > Proxy Binding Update and Proxy Binding Acknowledgment messages > > exchanged between MAARs. This option is used for exchanging the > > > > MAARs but not CMDs? > > When is this used in the PBU? > > > > [CB] Also CMDs. And only in PBA. Fixed. > > > > > > Section 4.8 > > > > A new DLIF Link-layer Address option is defined for use with the > > Proxy Binding Update and Proxy Binding Acknowledgment messages > > exchanged between MAARs. This option is used for exchanging the > > > > MAARs but not CMDs? > > When is this used in the PBU? > > > > [CB] Same as before. > > > > > > Section 6 > > > > Unfortunately it seems that RFC 5213 does not include any privacy > > considerations discussion. While the privacy properties of this > > protocol bear similarities to those of RFC 5213, it seems that there are > > also some significant differences, so I do think it is important to > > produce some documentation of privacy considerations for this document. > > The main factor would, of cousre, be tracking which entities obtain > > updates/information about the location of the MN, what those entities > > are expected to do with that data, and how trusted they are to be proper > > custodians of it. Other factors may exist as well, including the > > potential for side-channel information leakage, e.g., due to traffic > > analysis. There might also be a reverse situation where exposing the > > link-layer address(es) of a P-MAAR have privacy considerations, though I > > don't have anything particular in mind at the moment. > > > > [CB] OK, I see your point. I've tried to add something in version -06. Let > me know if you think it is sufficient (I tried to keep it short and simple, > while still addressing your point). I think it covers the key points. Since all the parties are highly trusted anyway, we don't need to go into great detail. > > > > > security concerns of Proxy Mobile IPv6 [RFC5213]. It is recommended > > that the signaling messages, Proxy Binding Update and Proxy Binding > > Acknowledgment, exchanged between the MAARs are protected using IPsec > > using the established security association between them. This > > > > This is essentially unchanged from 5213, just with different names for > > the endpoints, right, and so the existing guidance/experiences apply? > > > > [CB] Yes, it should apply. We haven't identified anything different. > > > > > > I think we should also say something about all MAARs and the CMD being > > trusted parties. We should also say something about the authorization > > model (I assume it's just "all trusted parties are trusted to perform > > all operations relevant to their role", but that's still useful to say). > > > > [CB] OK, I've added a sentence on that. > > > > > > When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of a > > single PBU to multiple previous MAARs. In situations of many fast > > handovers (e.g., with vehicular networks), there may exist multiple > > previous (e.g., k) MAARs exist. In this situation, the CMD creates k > > > > nit: remove the redundant "exist" > > > > [CB] Done. > > > > > > When the CMD acts as MAAR locator, mobility signaling (PBAs) is > > exchanged between P-MAARs and current S-MAAR. This requires security > > associations to exist between the involved MAARs (in addition to the > > ones needed with the CMD). > > > > Is this relevant because of scaling/resource-consumption concerns or > > keying/trust ones? > > > > [CB] This is relevant because RFC 5213 uses a model in which signalling is > exchanged only between LMA (the anchor) and MAGs (the access routers), > while in this document there are some operation modes that also involve > signalling between MAARs (the access routers). This was just to highlight > this point (it is related to the point you made before about the trust > model). Okay, thanks for the clarification. > > > > > Appendix A.5 > > > > not implement existing mobility protocols. Furthermore, a DMM > > solution SHOULD work across different networks, possibly operated as > > separate administrative domains, when the needed mobility management > > > > Hmm, separate administrative domains makes the risk of NAT relatively > > higher (per previous comment about NAT). > > > > intervention. The partially distributed DMM solution can be deployed > > across different domains with trust agreements if the CMDs of the > > operators are enabled to transfer context from one node to another. > > > > It would probably be worth expounding a bit more about this scenario and > > the necessary trust/authorization relationships, in the security > > considerations. > > > > [CB] As per other comment from IESG evaluation I've removed the two > appendixes. > > Huge thanks for your very good points! And thanks for all the updates! I will go update my ballot position now. -Ben _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
