Last Call Review of draft-ietf-dmm-pmipv6-dlif-04
review-ietf-dmm-pmipv6-dlif-04-tsvart-lc-ott-2019-10-14-00

Hi,

this document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The draft defines extensions to Proxy Mobile IPv6 to support a more distributed
variant of mobility management. In essence, as a mobile node moves from one
point of attachment (Mobility Anchor and Access Router, MAAR) to the next,
its routing prefix with the previous MAAR(s) remain(s) and ongoing transport
layer connections remain active and routed indirectly via the previous MAAR,
while new ones will use the present MAAR. The interactions of MAARs are
managed via a Central Mobility Database (CMD).

The draft is well written and good to follow, describing the protocols and
extensions clearly. I just have two transport-specific concern and two general
operational issues that require further clarification in the draft.

The transport issues:

T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates (PBUs)
and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU to
multiple previous MAARs. If multiple previous MAARs exist, say k, (and there
may be numerous in case of many fast handovers, e.g., with vehicular networks),
the CMD creates k outgoing packets from a single incoming packet. This bears
a certain amplification risk (which may also need to be addressed in the security
considerations section) but it also may lead to packet bursts originated from the
CMD, albeit to different targets. Other protocols start introducing pacing to avoid
bursts on the outgoing link, even if the packets do take different paths in the end.
This may be worthwhile considering.

T2. Also in section 3.2, when relaying PBAs, the CMD serves as a transport or 
application endpoint and should have a way to deal with missing responses
(after all, this is a connectionless protocol on top of an unreliable Internet).
A timeout is only mentioned for aggregation, but even there there the timeout
is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a timeout
used elsewhere.

General issues:

G1. Section 3.2 (again) specifies that responses are aggregated on p.10. How
does response aggregation work? How is error handling done?

Moreover, also on p.10, further below the draft states that if a timer expires,
the requests already received are forwarded. The missing ones come later.
This seems to contradict aggregation because the originator (the currently
server MAAR) does not expect more than a single response if it sent out a
single update. This may thus require updated processing in the MAAR.

G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous MAAR
to the current MAAR. How does this work if security associations are supposed
to be applied? It would seem that, when following the security considerations,
such cases are not covered. At least, this would warrant further explanation as
in this case we suddenly have three involved security associations, which would
also need to be established. 

G3. Sect 3.5 discusses deregistration and suggests that this can only be done by
timeout; I understand the rationale but can any risks arise on continued resource 
consumption (DoS attacks)? 

G4. Sect. 6.: As alluded to above, the security considerations may need expanding.

Nits:
p.12: "information are" -> "information is"
p.12: "influence on" -> "influence"