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

From: Greg Daley <[email-masked]>
Date: Tue, 06 Jun 2006 21:33:17 -0400

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

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 22 Jun 2006 18:23:14 +0900

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.

>   Router Advertisements rapidly without changes to IPv6 Neighbor

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.

> DNA is used in paragraph 2 without being introduced.

I added a text. 

>   <xref target="I-D.ietf-dna-protocol"/>.

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

> Please note that this restriction has been relaxed in RFC2461bis.

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

> s/broadcast/multicast/

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

> s/For DNA purpose/For DNA purposes/

ok.

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

> the PoA may trigger an AR to either sen

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

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

> s/, PoA may/, the PoA may/

ok.

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

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

>   control, and the RA message contents don't change often.

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

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

I added it in Introduction.

> s/If incoming/If an incoming/

ok.

>   <xref target="RFC2461"/>.

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

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

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

> s/attachement/attachment/

ok.

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.

> DoS Attacks seem to be ignored here.

I mentioned about excessive signaling.

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

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

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

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

---

From: JinHyeock Choi <[email-masked]>
Date: Thu, 22 Jun 2006 19:13:39 +0900

Dear WG

We have updated the FRD draft. It's not in the repository yet 
but available in

http://www.diffeo.com/drafts/draft-ietf-dna-frd-01.txt

Mainly we reflected the changes which happened since the 00-version
such as DNA solution progress & 802.16 ISF (Initial Service Flow)
definition. Also we incorporated feedback from WG, special thanks to
Greg for detailed comments. Additional new text was introduced in last
2 paragraphs of section 4 and last 2 paragraphs of the security
considerations. Please give your opinion on the addition.

Kindly see that everything is ok. We wish to LC the draft in near
future, so your feedback would be appreciated.

Authors