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

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi, 

Here is a review of FRD.  I will be travelling for 
the next two weeks, so my response will be limited.

Greg


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


Abstract


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




Introduction

DNA is used in paragraph 2 without being introduced.

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"/>.
   

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.


Paragraph 5:

s/broadcast/multicast/

s/For DNA purpose/For DNA purposes/

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/


s/, PoA,/, the PoA/

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


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

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/


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.



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.


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.



5.1.2 Scanning


Note that there is no description of a suitable RA.


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/

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"/>.



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

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.



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.

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.

7. Security Considerations

DoS Attacks seem to be ignored here.

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.

s/through secure port/through a secure port/

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.




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


-----------------------------------------

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