Subject: [DNA] WGLC for draft-ietf-dna-frd-02.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 06 Sep 2006 18:14:48 -0400

This mail starts a 2 week WG Last Call for comments for the following
dna working group document

draft-ietf-dna-frd-02.txt

to be sent to the IESG for consideration as an INFORMATIONAL RFC.

Please review the document carefully, and send your feedback to the
list. Please also indicate whether or not you believe that this
document is ready to go to the IESG.

The last call will end on 2006/09/20. Please comment as early as
possible to allow the authors to incorporate the comments before the end 
of the LC.

Thanks
Greg and Suresh
(dna chairs)

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Sep 2006 11:29:59 -0400

Some quick comments.

Note that this is not a detailed review. I think there are some bigger
issues to discuss first before I'm willing to do a detailed review.

First, what is the intended publication type? informational? (Hmm,
later I see it has what seems like a protocol change regarding
Ownership Proof. That would seem to imply standards track. What is
it?)

Second, the document title is misleading. Rather than calling this
"fast router discovery", I think it should be called something like
"triggered router discovery", since the whole point is to have the
sending of RAs triggered by a link up type event.

One issue with RA proxying is that the info in a cached RA may be old
and invalid. RAs include lifetimes in units relative to "now". Caching
an RA for (say) 15 minutes means that the lifetime information in that
RA is now potentially very incorrect. Are proxies supposed to muck
with lifetimes and decrement them in real time? Note that this would
presumably break SEND (and any other way of securing RAs). I don't see
discussion of this anywhere.

The security considerations talks about some of this, but includes:

   We may resolve this issue by including a unique 64 bit number called
   an Ownership Proof (OP) in an RA.  The 64 bit number, OP, is the hash
   of a nonce and proves to a host that the RA was indeed generated by
   the router which is listed as the source of the RA.  The router must
   keep a table associating each OP to the nonce, which was used to
   generate it.  When an RA carrying an OP option is received, a host
   may ignore the SEND Timestamp option if it falls outside the
   allowable window.

is this a required part of the spec? Where is the OP field defined?

Reading through the algorithms, I'm pretty dubious of this, plus its
way out of scope for this WG to be defining such changes.

Some of the references need updating and or an evaluation of whether
they are really normative. For example:

>    [4]   Kempf, J., "Detecting Network Attachment in IPv6 Networks
>          (DNAv6)", draft-ietf-dna-protocol-01 (work in progress),
>          June 2006.

is listed as a normative reference. Given that this document can't be
published until all normative references are also ready, I wonder if
we should be advancing this document at this time. Seems like we
should wait until the merged document is done before advancing other
documents that depend on it.

Section 5.1.2 scanning, says:

   First it scans the L2 frame header to see whether it is a multicast
   frame.  If not, the PoA sends that frame down link and scans the next
   L2 frame.  If so, the PoA looks IP header to check whether it
   contains a suitable RA.  If an incoming L2 frame doesn't contain a
   suitable RA, the PoA sends that frame down link and scans a next L2
   frame.  When the PoA finds a suitable RA, it stores it and sends a
   copy down link.

The above seems incorrect, since RAs can be unicast. Yet, we only scan
for multicast ones?

   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, we can control the scanning rate.  For example, we
   can set timer and execute scanning every T seconds.

This strikes me as bizarre/broken and can easily lead to the caching
of old information. We shouldn't recommend something like this.

Thomas

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 08 Sep 2006 16:33:50 +0900

Quick question on this document,

While glancing at the draft-ietf-dna-frd-02, I can see lot of
MIH relevant facilities to commend and trigger on the PoA. 
I am wondering what happen without MIH capability on the 
PoA ? If we can live with frd regardless of MIH capability,
that would be better I believe since MIH (802.21 standard)
is still under construction...

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: Wassim Haddad <[email-masked]>
Date: Sat, 09 Sep 2006 17:42:54 +0300 (EEST)

On Thu, 7 Sep 2006, Thomas Narten wrote:

> First, what is the intended publication type? informational?

=> the intention is to publish it as informational.

> (Hmm, later I see it has what seems like a protocol change regarding

=> Maybe we should move these two sections to appendix to avoid any
confusion.

> sending of RAs triggered by a link up type event.

=> Thank you for raising this point. I agree the title should reflect the
triggering process but also the consequence of such triggering.

> discussion of this anywhere.

=> Proxies don't decrement lifetime. In practice, RA information seldom
changes. Usually routers send the same RA again and again.

> is this a required part of the spec? Where is the OP field defined?

=> OP is an add-on feature to facilitate the interoperability with SeND.
It will be defined in further work.

Regards,

Wassim H.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Sep 2006 14:39:42 +0300

I have also performed a quick review of this spec.

Overall, the draft addresses a significant problem
and we need a solution in this space. However,
more work is needed and I would suggest taking
the draft back to the editors and have them
prepare a new proposal based on the high-level
comments received so far.

Multiple mechanisms: The draft suggests a variety
of mechanisms as opposed to choosing one. The draft
uses either triggering or caching. For triggering,  the
draft uses either an RS with the tentative option, or MIES.
For caching, the draft allows manual config, learning based
on RAs, or MICS. Sometimes we have to have multiple
mechanisms, but I'm not sure I see the rationale for that
here. Perhaps there was past discussion that I did
follow. But I would suggest that the WG/editors consider
the choices and make the necessary hard decisions.
For instance, it seems that triggering via rs+tsslao
avoids most problems, as it does not need multicast
RAs, does not impact SEND AFAICT, and has no
impact on advertised lifetimes.

RS with tentative address construction: This is
not discussed in the draft. Source = undefined,
tsllao = poa's L2 address? And I'm assuming responses
to such RSes will be valid RAs in all existing hosts that
only support RFC 2461?

Unicast RA construction: Is there a description of what
the contents of the RA sent from the cache are? It
is mentioned that it is sent in an unicast L2 frame,
but are there any changes to the IP packet, e.g.,
destination address, lifetimes, etc?

Scanning procedures: I agree with Thomas' observation
about the alternative scanning procedure. Also, I
don't think Section 5.1.2 should recommend anything
about AR behaviour, and should operate on standard
IPv6 routers.

802.16: There's very little DNA specific information
here, and a lot of information that is overlapping
with 802.16, Wimax Forum, or 16ng WG tasks. I
would suggesting deleting this section.

Damping: I suspect that a damping procedure should
be defined to avoid causing RS storms due to attachments
that relate to ping-ponging between nearby networks,
a large number of hosts arriving at the same access point
and so on.

Dangling references. Draft-ietf-dna-tentative is
a pointer to an expired draft, and the merged
document is not yet available. There is no pointer
to the OP procedure. The hash chain procedure
is defined in an individual draft which is currently
not on the program in any WGs as far as I can
remember. And a new SEND solution is not in
DNA's charter.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 10 Sep 2006 14:40:25 +0300

Hi Wassim,

>=> Maybe we should move these two sections to appendix to avoid any
I don't think that helps. Either we have a complete spec in this
document, or we have normative references to other specs that
define these things. If we go for the normative references, then
those should be RFCs or at least we should be reasonably certain
that they will become RFCs in a timely fashion.

Alternatively, if the protocol changes are not really needed
for the DNA spec then they can be pursued separately.
In general, security is not something that can be pushed
off this way, however. Though this case is a bit special.
I have not formed a strong opinion yet if the caching actually
is a problem for SEND. Or whether its a problem depends
on how you perform FRD. My first reaction would be to
avoid the problem, since some of the solutions in the draft
do not appear to have a problem with SEND.

>triggering process but also the consequence of such triggering.
I like the new title suggestion too.

>changes. Usually routers send the same RA again and again.
That lifetimes are not decremented does help with
the SEND impacts. But then you have another
issue that the scheme is limited to situations where
keeping the lifetimes constant does not harm anyone.
What if you see an RA at time t_0 and a host at time t_1,
with the prefix lifetime in the RA < (t_1 - t_0)? Would
you need an applicability statement or even protocol
mechanisms to avoid such situations?

--Jari

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 11 Sep 2006 12:19:29 +0900

Dear Jari

Thanks for your feedback. Kindly find my inline comments.

> comments received so far.

ok.

> the choices and make the necessary hard decisions.

We presented multiple mechanisms because network environment may
differ and there may be different applicability scenario for each
scheme. For example, in WiMAX, whenever an MN makes an attachment, the
AR, ASN GW, perceives a new attachment during registration procedure.
Therefore RA triggering (without RS with tentative option) is more
suitable. On the other hand, RA proxying with scanning can work with
ordinary router without any modification.

> impact on advertised lifetimes.

Glad that you seem to like the idea. However the scheme necessitates
router modification to handle tentative option and people showed some
concerns. Kindly find following exchange between Greg and me.

  [JinHyeock]
  Main difference between MN soliciting and AP soliciting is that,
  with the latter, we can realize a scheme (similar to Hash based
  FastRA) in a simpler way.

  We can assume that an AP knows all the ARs in a link.
  So AP can send UNICAST RS (to remove random delay)
  and solicit ARs in turns (for load balancing).

  When a new host is attached to the AP,
  AP can sends an unicast RS to a chosen AR
  1) with unspecified source address
  2) with the host's MAC address in TSLLAO.

  Upon receiving the unicast RS,
  the AR can send an RA immediately
  (because it is solicited in unicast).
  in unicast (using TSLLAO)

  Also AP take turns to solicit ARs,
  such as this time AR1 next time AR2
  to achieve load balancing.

  Hence no load balancing mechanism is needed
  in ARs.

  [Greg]
  > When a new host is attached to the AP,
  > AP can sends an unicast RS to a chosen AR
  > 1) with unspecified source address
  > 2) with the host's MAC address in TSLLAO.
  >
  > Upon receiving the unicast RS,
  > the AR can send an RA immediately
  > (because it is solicited in unicast).
  > in unicast (using TSLLAO)
  >
  > Also AP take turns to solicit ARs,
  > such as this time AR1 next time AR2
  > to achieve load balancing.
  >
  > Hence no load balancing mechanism is needed
  > in ARs.

  This is actually using the hackiest part of TSLLAO ;)
  In some devices it won't be possible to modify the
  outbound MAC address of the packet on the router, but
  it seems in this environment, you could either discover
  the ones which handle the TSLLAO, or mandate modified
  routers.

  Should we leave that part in the TSLLAO draft for
  the moment then? :)

  > > Surely the same logic is needed for the AP or there would be
  > > collisions if there are multiple routers on the link.
  >
  > Yes, AP needs some logic (but simpler one, in my opinion) and
  > for hosts and routers, only TSLLAO is needed.
  > Other than that there is nothing to change in them.
  >
  > How do you think of it?

  I think that if protocols were in a beauty contest, it would
  be the ugliest cheetah around.

  It's really not possible to tell how much simpler it is, though.
  The APs need to track a list of all routers, some of which may
  not be trusted at L3 (Do they do SEND?).  In each of the ARs,
  the RA delivery scheme needs to be modified (TSLLAO w/o Ncache,
  Delay removal for Unicast RS).

  In other schemes, ARs need to track other DNA routers. In
  each of the ARs, modifications to the RA delivery scheme are
  needed (TSLLAO, delay + scheduling modification, unicast response).

> to such RSes will be valid RAs in all existing hosts that

yes.

> destination address, lifetimes, etc?

In IP level, the RA has 'multicast destination address'. In MAC level,
the RA has the address from tentative option as a destination address.

> about AR behaviour, and should operate on standard

ok.

> would suggesting deleting this section.

The section presents how FRD works without MAC address. 802.16 doesn't
use MAC address for the data transfer, so we showed how RA is
delivered with CID, instead of MAC address. We were concerned that
people are not familiar with 802.16, so presented some 802.16
information.

> a large number of hosts arriving at the same access point

ok.

> remember. And a new SEND solution is not in

ok. We'll make a fix.

I am off to Mannheim for 16ng interim in an hour. This week my reply
may be erratic, so I ask your kind understanding.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 11 Sep 2006 12:28:02 +0900

Dear Daniel

> is still under construction...

FRD can work without MIH. We just tried to show how MIH can be used to
facilitate FRD operation. Greg showed a similar concern. If the
section gives the wrong impression that MIH is indispensable for FRD,
we may remove it to Appendix. (FRD can use MIH, if it's there.)

Best Regards

JinHyeock

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 15 Sep 2006 09:19:07 +0900

> we may remove it to Appendix. (FRD can use MIH, if it's there.)

My preference is an Appendix if acceptable. 

Thanks,