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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sat, 02 November 2019 11:45 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 49CB3120EA9 for <dmm@ietfa.amsl.com>; Sat, 2 Nov 2019 04:45:22 -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 eUdFcT-VteWO for <dmm@ietfa.amsl.com>; Sat, 2 Nov 2019 04:45:18 -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 10B7B1213E2 for <dmm@ietf.org>; Sat, 2 Nov 2019 04:45:18 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id p59so9441723edp.7 for <dmm@ietf.org>; Sat, 02 Nov 2019 04:45:17 -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=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=nAV7SZSZaSaY0VhNCfKKiX576UJLCpjr4GQ9tNwhj9/MQ67e/QlXz6rLSA7xlph/UT 3VazXn3X6drNshoFhh6l6XYkNj1ApGKcR8jkJu0kSJl9vGYobK16Sl96NYbNVSUNGNNN aADqe8ubLHwhhMMWmPiSOy7UyYUA93cGwDR6J4cSdV0TkfKYY3p5EmQ7btwPbdTpyPyB Ju1661iNirywP/e26zxX8mUig5TxRb7x0XH2K1HZlOyx9LOgnSTjxArEkwcVFsg9c779 qz4tAC2g2fiBxdrHLI5gi1PQJzKo6xMyEF1FlMiCWadhzrRmIXSmq55mF/lmsBx+LwB/ Lz5A==
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=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=mqOVBLk0ZjhA/hCID8/nv/hovS/5/2BviJDzsrBA0VDf+tZ73vofwWQ45A7meFbnLk DWd5PSQ1JWUwCRlxJ7uBLl7pLbKImUBEeIQoT0pBTBDPEtBRZebKET42tr0X29NSVNiB zL6vHrVkRHqtw1aT3HrYZbew9VMVXt/ycD5Ix610FroC2/MB45Fu7O0PzMmE7UZJN5ga 4cUf5T9TuOSckUQMe6QIiOfkk5arkuWnFAZ1lOZSUGOUxQZdmIHsRHi6MMPO5ZFR0Rnz S2cds3oNMRC372qW9jC/Xdzj5hUM7FqiqO1HqkH57Ew9A4XNk4IyvpUMXJ3IfcUXGyge hZkA==
X-Gm-Message-State: APjAAAX1gN6qK+HuGJbYkHD5uVSP8B5Awc1NrJDvEmhpJF1GOaCxICzJ 1Wd3QZAJWCqgDNqmR/kw1di4mr7ENpQSeMJA3hSdsQ==
X-Google-Smtp-Source: APXvYqyMg9u+FQN8yjW5bbJ3saZU6ASCWr7o2kNaxodf+eTNakKybBufK71tbhOc+FSoSoSgXhM7756TWX9eRG1A0XI=
X-Received: by 2002:a17:906:448e:: with SMTP id y14mr14770700ejo.136.1572695116290; Sat, 02 Nov 2019 04:45:16 -0700 (PDT)
MIME-Version: 1.0
References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> <CALypLp-sHu4-GM6MqCHwGAGhkp8Bb-0GcTQeB=VMO8yiCi6Z1g@mail.gmail.com>
In-Reply-To: <CALypLp-sHu4-GM6MqCHwGAGhkp8Bb-0GcTQeB=VMO8yiCi6Z1g@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sat, 2 Nov 2019 12:45:00 +0100
Message-ID: <CALypLp9WtOSCH-jiWsV_SDedicsoqS_-a2MUWXzwOCN5hG22zQ@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="000000000000bf3eb305965b9d43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/rTZn7mMv1GlCEXcE2rToeKWhQwk>
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: Sat, 02 Nov 2019 11:45:27 -0000

Hi Joerg,

We've just posted a new revision addressing your comments.

Thanks,

Carlos

On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>;
wrote:

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

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