[DNA] Re: Review of draft-ietf-dna-frd-00.txt

[JinHyeock Choi <jinchoe@samsung.com>]

Dear Greg

Thanks for your kind and detailed feedback. Kindly find my inline comments.

> This document has expired in the repository, please submit a new version.

ok.

> Please do not make any abbreviations in the abstract.  Abbreviations
> should be introduced on their first use in the text.
>
> It's not clear what the optimized result is...
>
> The Suggested abstract is as follows:
>
>   For efficient detection of network Attachment, a host should quickly
>   receive a Router Advertisement upon a new link-layer connection.
>   This draft presents a quick advertisement acquisition scheme with
>   the support of a link-layer Point of Attachment.
>
>   Upon a new network attachment, the Point of Attachment may either
>   trigger an Access Router to immediately send a unicast advertisement
>   "RA Triggering" or send such an advertisement itself "RA Proxying".
>   Such functions may be placed on a Point of Attachment to deliver
>   Router Advertisements rapidly without changes to IPv6 Neighbor
>   Discovery

I checked a few RFCs, such as SeND (RFC 3971), and found out they also
uses abbreviation in the abstract. Also DNA Goals (RFC 4135), which we
co-authored, includes abbreviations in the abstract. Also when we
wrote DNA Goals, Jim Bound explicitly objected 'abstract' to be
separated into two parts as above.

> Introduction
>
> DNA is used in paragraph 2 without being introduced.

I added a text. 

> Paragraph 2 and 3 overlap in coverage.
>
> Here is a suggested amalgamation:
>
>
>   A host needs to receive a Router Advertisement (RA) when it has moved
>   to a different link in order to Detect Network Attachment (DNA).
>   Router advertisements contain IP prefix information which identify
>   the composition of a link, and the available prefixes to configure
>   upon link change.  This document focusses on Rapid delivery of RA
>   messages without describing their content <xref target="RFC4135"/>.
>   Those interested in RA contents are referred to
>   <xref target="I-D.ietf-dna-protocol"/>.

I modified the phrases including the definition of 'a suitable RA'.

> In Paragraph 4, please change sentence beginning "Second, ..."
> as follows:
>
>   Second, a host should randomly delay before initial transmission
>   of a Router Solicitation (RS) message.
>
> Please note that this restriction has been relaxed in RFC2461bis.

ok, but I prefer 'delay random amount of time'.

> Paragraph 5:
>
> s/broadcast/multicast/

because there is 'over wireless link', I prefer 'broadcast'.

> s/For DNA purpose/For DNA purposes/

ok.

> Paragraph 6:
>
> s/PoA (Point of Attachment) is the link endpoint fo the link, such as/
> A PoA is a link-layer connection point through which a wired or wireless
> host
> interfaces to an access network, such as/

This is how PoA is defined in Bernard Aboba's DNAv4 (RFC4436). When he
wrote the draft, we had a discussion about the terminology to synchronize 
DNAv4 and DNAv6. I guess we'd better be in sync with the existing definition
unless that's unacceptable. 

> s/, PoA,/, the PoA/

ok.

> s/delivered to the host in unicast/unicast to the host/
>
> Paragraph 7:
>
> s/the PoA may either trigger an AR (Access Router) to immediately send a
> suitable RA or/
> the PoA may trigger an AR to either sen

Please elaborate more. The current ones seem better to me.

> Protocol Overview:
>
> Paragraph 1:
>
> I suggest replacing the text with:
>
>   Using the procedures outlined in this document, when a host establishes a
>   link-layer connection a PoA, can detect the host's new attachment and get
>   the necessary information to deliver an unicast L2 frame to it. For
>   example, this link-layer information may be a 802.11 MAC address or
> 802.16
>   CID (Connection Identifier) [19].

I can't see the benefit of a change. Please elaborate more. The
document doesn't intend to outline the procedures for a PoA to detect
the host's new attachment and get the necessary information to deliver
an unicast L2 frame to it. Those are given and out of scope and
described only when necessary for explaining FRD process.

> Paragraph 2:
>
> s/forward the information/forward the link-layer information/
>
> Paragraph 3:
>
> s/Or the PoA/Alternatively, the PoA/
>
> 3.1 RA triggering:
>
> Paragraph 1:
>
> s/to IP layer/to the IP layer/
>
>
> Paragraph2:
>
> s/deliver the AR the Link Up event notification/
> deliver a Link Up event notification to the AR/
>
> Paragraph 3:
> s/TSLLAO/Tentative Option/
>
> 3.2 RA proxying:
>
> Paragraph 2
>
>
> s/We may manually/An administrator may manually/
>
> s/use the scanning scheme/use an RA scanning scheme/
>
> s/Or PoA and AR may use a special information service/
> Alternatively, a PoA and AR may use an information service/
>
> s/porxy/proxy/
>
> Paragraph 3
>
> s/, PoA may/, the PoA may/

ok.

> 4. RA Triggering
>
> Suggest replacement of paragraph 1 with:
>
>   In case the PoA and AR are in the same node, when a new host is attached
>   link-layer events may be delivered locally.  The arriving host's
> link-layer
>   address can be passed from the PoA (Link-Layer) to the AR (IP Layer) in
>   the same stack.  Subsequently, the AR can immediately send a suitable
>   RA in a unicast L2 frame with the new host's MAC address.
>
> Paragraph 2:
>
> s/, we may use/, they may communicate using/
>
> Paragraph 4:
>
> Add to the end:
>
> Further deatils of these operations are provided in section 5.1.3.

I prefer the current ones. For example 5.1.3 is not about further
details of 4. Please elaborate whey changes are needed.

> 5. RA proxying:
>
> paragraph 1:
>
> s/we recomment to use RA triggering instead/
> it is RECOMMENDED that RA triggering is used instead/
>
> 5.1 RA Caching:
>
> Replace with:
>
> Three different methods for storing RAs in a PoA are presented.

I prefer the current ones. For example, this is intended as an
Informational and why should we RECOMMEND? Please elaborate whey
changes are needed.

> 5.1.1 Manual Configuration:
>
> please replace with:
>
>   In the simplest way, an administraotr can manually configure a
>   suitable RA in the PoA.   Such an RA may contain a link-identifier
>   or be a Complete RA <xref target="I-D.ietf-dna-protocol"/>.  This
>   may be applicable where the AR and PoA are under the same administrative
>   control, and the RA message contents don't change often.

I modified the text with the term 'a suitable RA'.

> 5.1.2 Scanning
>
> Note that there is no description of a suitable RA.

I added it in Introduction.

> paragraph 1
>
> s/L2 frame /L2 frames /
>
> Paragraph 2:
>
> s/scans L2 frame/scans the L2 frame/
>
> s/sends that frame down the link and scans a next L2 frame/
> ignores that frame for caching purposes/
>
> s/If incoming/If an incoming/

ok.

> Paragraph 3:
>
> Please replace the paragraph with:
>
>   A PoA can scan continuously, updating an old RA with a new RA.
>   Alternatively, if it costs too much for the PoA to scan every
>   incoming L2 frame, it may control the scanning rate.  For example,
>   it can set a timer and execute scanning every T seconds, Or the PoA
>   itself can send a Router Solicitation (RS) message periodically.
>   It is noted that the PoA doesn't need to have an IP address since
>   it can use the unspecified address as its RS source address.
>
> Paragraph 4:
>
> Please replace with:
>
>   It assists RA caching if routers advertised changed parameters
>   rapidly as described in section 6.2.6 of IPv6 Neighbour Discovery
>   <xref target="RFC2461"/>.

I don't see much difference from the current one. Please elaborate
whey changes are needed.

> 5.1.3 MICS (Media Indepenent Comment (sic) Service)
>
> Globally:
>
> s/Comment Service/Command Service/
>
>
> Paragraph2:
> s/Remote MIH Command, "MIH Network Address Information"/
> Remote MIH Command Primitive: "MIH Network Address Information"/

I checked with Xiaoyu, 802.21 secretary, and he recommended the
current one. 'Primitive' is used inside local stack.

> Paragraph3:
> it greatly concerns me that this paragraph suggests standardization
> by someone "we"! that a new 802.21 Command service primitive is defined
> for this role.
> As described in 7.4.11 of 802.21 D01.00, Network Address Information
> request can be used to gather addressing and routing information on the PoA.
>
> There are still uncertainties there regarding the content of messages,
> and any recommendations seem highly conjectural for a document aiming
> to be an RFC.
>
> Perhaps such suggestions should be placed in the appendix.

I see your point. I made a comment at the end accordingly. Also, if
needed, we can move it to Appendix.

> 5.2 RA Delivery
>
> s/attachement/attachment/
>
> s/describes/described/
>
> 5.2.1 802.11
>
> No mention of how this works with 802.11i RSN is made.
>
> This needs to be fixed.

ok.

> 5.2.2 802.16
>
> Paragraph 3 and Paragraph 7
> Both seem to indicate that 802.16 procedures are not
> well enough developed to normatively describe.
>
> This section should be removed or moved to an appendix.
>
> My concern here is that it's implicitly putting requirements
> on 802.16 for the channel establishment operations.

The main concern was that the connection to be used for ND 
is not decided but now it become more clear. ND messages
can be carried in a separate transport connection, ISF (Initial
Service Flow). I reflected that into the text.

> 7. Security Considerations
>
> DoS Attacks seem to be ignored here.

I mentioned about excessive signaling.

> parrticularly:
>
> Paragraph 3:
>
> It's wrong to say there's no FRD specific problem, as
> false or spurious Associations (caused by a sequence of
> L2 messages) can be used to trigger an additional RA
> on the PoA.   This is a potential amplification attack
> in some scenarios, and consumes wireless medium bandwidth.

I mentioned that in relationship with excessive signaling.

> s/through secure port/through a secure port/

ok.

> Paragraph 4:
>
> It is wrong to say there is no additional security vulnrebility
> if there's not a secured path between PoA and AR.
>
> An on-link attacker can potentially forge MICS events which
> can force the Router to place configuration information on
> the PoA.
>
> An attacker can also fill the PoA's cache with false router advertisements,
> which can make change undetectable for nodes transiting from an
> adjacent link.  This will significantly slow change detection.

I modified the text. But take notice, even without FRD, an attacker
can send a bogus RA for itself to mislead the DNA decision.

> Paragraphs 6-9
>
> Ownership proof is best not hidden in the Security considerations
> section. It's clearly the crux of how to cache securely.
>
> You need to ensure that the Solicited RA (from the RS with the OP
> option) contains a valid Timestamp option though, and that the
> solicited timestamp is within range.
>
> Please state this (and that an OP on the subsequent RA cannot
> be used as proof instead).

OP part is intended to sketch a scheme. So I guess general overview is
ok and wonder it's necessary to delve into details.

> -----------------------------------------
>
> idnits 1.101
>
> tmp/draft-ietf-dna-frd-00.txt:
>
>
>  Checking nits according to http://www.ietf.org/ID-Checklist.html:
>
>    Checking conformance with RFC 3978/3979 boilerplate...
>
>    the boilerplate looks good.
>
>    No nits found.
>
>  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>    Nothing found here (but these checks do not cover all of
>    1id-guidelines.txt yet).
>
>  Miscellaneous warnings:
>  - The document seems to lack the recommended RFC 2119 boilerplate, even if
>    it appears to use RFC 2119 keywords.
>
>    RFC 2119 paragraph 2 text:
>    "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119."
>
>
>  Experimental warnings:
>  - Unused Reference: [2] is defined on line 474, but not referenced
>    '   [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address'
>
>  - Unused Reference: [3] is defined on line 477, but not referenced
>    '   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)'
>
>  - Unused Reference: [6] is defined on line 488, but not referenced
>    '   [6]   Nordmark, E. and J. Choi, "DNA with unmodified routers:
> Prefix'
>
>  - Unused Reference: [8] is defined on line 496, but not referenced
>    '   [8]   Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in'
>
>  - Unused Reference: [11] is defined on line 506, but not referenced
>    '   [11]  Pentland, B., "An Overview of Approaches to Detecting Network'
>
>  - Unused Reference: [15] is defined on line 522, but not referenced
>    '   [15]  Aboba, B., "Detecting Network Attachment (DNA) in IPv4",'
>
>  - Unused Reference: [16] is defined on line 525, but not referenced
>    '   [16]  Nordmark, E., "MIPv6: from hindsight to foresight?",'
>
>  - Unused Reference: [17] is defined on line 529, but not referenced
>    '   [17]  Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router'
>
>  - Unused Reference: [18] is defined on line 533, but not referenced
>    '   [18]  Daley, G. and J. Choi, "Movement Detection Optimization in'
>
>  - Unused Reference: [20] is defined on line 541, but not referenced
>    '   [20]  IEEE 802.16 TGe Working Document (Draft Standard), "Amendment'
>
>
>    No nits found.
>
> General:
>
> please remove references to:
>
> draft-ietf-dna-soln-frame-00              (deprecated)
> draft-ietf-dna-cpl-01  (unless referenced from paragraph 2 of introduction).
> draft-jinchoi-dna-protocol2-01            (linkid related)
> draft-mkhalil-ipv6-fastra-05              (?, is it going to be referenced?)
> draft-nordmark-mobileip-mipv6-hindsight   (linkid related)
>
> Please update references to:
> draft-ietf-send-ndopt-06 --> RFC 3971
> draft-ietf-dhc-dnav4-16  --> RFC 4436
> draft-daley-ipv6-tsllao-02 --> draft-ietf-dna-tentative-00
> draft-pentland-sna-protocol-01 --> draft-ietf-dna-protocol-00
> draft-ietf-dna-link-information-02 --> draft-ietf-dna-link-information-03
>
> IEEE 802.21 draft D00.01   --> D01

I changed the draft number but prefer remove the ref at the last
moment. (It's easier to remove than add.)

Thanks for your kind consideration.

Best Regards

JinHyeock