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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Fri, 18 October 2019 11:24 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 D012E120BE6 for <dmm@ietfa.amsl.com>; Fri, 18 Oct 2019 04:24:30 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 DGElgii2ifB1 for <dmm@ietfa.amsl.com>; Fri, 18 Oct 2019 04:24:26 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 100C2120C0D for <dmm@ietf.org>; Fri, 18 Oct 2019 04:24:26 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id f20so4278085edv.8 for <dmm@ietf.org>; Fri, 18 Oct 2019 04:24:25 -0700 (PDT)
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=D6dfZgRiPvICC3k64jiOVzv8fCBiufwvTQmJ1mkvIoA=; b=rn/aSsPbw8lokV8avqlDNWwipUmhCCNhHs9EnzgTlZMz8qeSy4EZp/pW6ZeDJlSqTA a0BcTtd0RBxwRwP+pqysbaK8Il5t75sUNAKF3mTFLhX4CnFF8DcYpgopkY7N/fT2K08E L8tpFXdGtl4d92g1u56zxofbCJcfP30PR0gT/UowGXtLZ1rAPUwjnorsKkj9gq5D2JBf eo6BnJX8m0s3Y07kFk12CPgl4uGo8izArpTXyBobJ7oybRbZ7OY9N0m+S/NeLWiKhj39 YQ6moPQFbLr3rE1hj+v38D5BMmvC6WuUL+4OXnzJs5rUX6eEDRJxr0rgOEzT7rFJlL/I 2uMA==
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=D6dfZgRiPvICC3k64jiOVzv8fCBiufwvTQmJ1mkvIoA=; b=oTaxT17NRaqKWvAcpv7ZgFbJ75awV9jlPXvXvVU5k3scnCzBtjJvy/XJ2I+yG8Uhl1 MDnbUsGxpyttc8+tNpDqoGZ8ndW0SIPKyqeujvgVd5mMVxwLfiXuZF1ZE2O6Nh2yq7Na 5+1CJ0HoxCqN1LzfRbCq0wsD6hXPejWYcuVRLWI52QDI0tg0p8COu5VMG57/p8iftns7 iIrhi56PooEb8wTKvn1or4ThWRhzVzkWN2yueFfQaJU+9bRDz6/2p3oekWUzKApyR6Lz N2GdPhrLb14fIhZYl/UxD2E8fUftBrJXSSJ0BPWd/0Td4GWtU6k6sEF7ClhwrfpqyxtL trGw==
X-Gm-Message-State: APjAAAWFt7PP8j5nQhbOenmftS4H6eNqv9XbHr9NjcGArUv85IACykkV u5NZpU+UXhpP9DsBUTCousuM/Rpm57aYDP06W1dnGg==
X-Google-Smtp-Source: APXvYqxPjeeCXe6famlnxfBUyyPuBypgPWbzWQ5bPJ+Lpm0CSr257meya8cDnOs1n72vctD1qHfbmzYP29hg/N3ocqI=
X-Received: by 2002:a17:906:8308:: with SMTP id j8mr8191530ejx.29.1571397864293; Fri, 18 Oct 2019 04:24:24 -0700 (PDT)
MIME-Version: 1.0
References: <157108615425.24656.12786623966649135975@ietfa.amsl.com>
In-Reply-To: <157108615425.24656.12786623966649135975@ietfa.amsl.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Fri, 18 Oct 2019 13:24:08 +0200
Message-ID: <CALypLp-sHu4-GM6MqCHwGAGhkp8Bb-0GcTQeB=VMO8yiCi6Z1g@mail.gmail.com>
To: Joerg Ott <jo@acm.org>
Cc: tsv-art@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000809ff305952d93bf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/Jy0dMt9u6kdbtNZTuxG66IlDjjo>
Subject: Re: [DMM] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04
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: Fri, 18 Oct 2019 11:24:31 -0000

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 <noreply@ietf.org>;
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
> 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"
>
>

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