Re: [DMM] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Thanks a lot Joerg for your very comprehensive review.

We will carefully look at your comments and provide responses (with
proposals of text changes) in the next few days. I prefer to take some time
to properly address all your points.

Thanks!

Carlos

On Mon, Oct 14, 2019 at 10:49 PM Joerg Ott via Datatracker <[e-mail]>
wrote:

> Reviewer: Joerg Ott
> Review result: Ready with Issues
>
> 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
> [e-mail] 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"
>
>

-- 
Special Issue "Beyond 5G Evolution":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g