Subject: Re: Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Sat, 2 Nov 2019 12:45:00 +0100

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 <[email-masked]>
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 <
> [email-masked]> 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
>> [email-masked] 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

---

From: Joerg Ott <[email-masked]>
Date: Sun, 3 Nov 2019 14:48:35 +0100

Hi Carlos,

thanks much, will review shortly, but this will take about a week
and a bit.

Best,
Jörg

On 02.11.19 12:45, CARLOS JESUS BERNARDOS CANO wrote:
> On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     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
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Reviewer: Joerg Ott
>         this document has been reviewed as part of the transport area
>         review team's
>         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
>         [email-masked] <mailto:[email-masked]> 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
>         its routing prefix with the previous MAAR(s) remain(s) and
>         ongoing transport
>         layer connections remain active and routed indirectly via the
>         previous MAAR,
>         extensions clearly. I just have two transport-specific concern
>         and two general
>         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.
>         (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
>         Moreover, also on p.10, further below the draft states that if a
>         timer expires,
>         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
>         in this case we suddenly have three involved security
>         associations, which would
>         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
>         G4. Sect. 6.: As alluded to above, the security considerations
>         may need expanding.
> 
>         Nits:
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>

---

From: Joerg Ott <[email-masked]>
Date: Mon, 18 Nov 2019 06:51:32 +0800

Hi Carlos,

thanks for the update.  I checked and, well, I was hoping for more than
just a few statements in the text reflecting my comments below.
Actually, I was wondering if some of the protocol mechanisms would need
updating to make sure that everything works.

Given that the target of the document is experimental, missing bits may
not be such a big deal, it is for experimentation after all.  Still, for
example, pacing could be spec'ed more precisely.  And I am not sure how
much you guys thought about security associations altogether (I am not
a security person and I don't play one on TV either).  The secdir review
provided other comments.  Are all those taken care of now?

Best,
Jörg