Subject: [DNA] Review of draft-ietf-dna-link-information-03.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 May 2006 13:28:26 -0700

Review of draft-ietf-dna-link-information-03.txt

Overall, I think this document has some issues:

a. The document appears to apply to both IPv4 and IPv6, but it makes a 
number of statements that do not reflect the operation of DNAv4 as defined 
in RFC 4436.  For example, DNAv4 does not utilize "link down" events or make 
use of link layer "hints".

b. A terminology section is needed, and terminology
consistency needs to be improved.  For example the terms
"event notifications" and "link layer events" are used. It
is not clear to me if these are synonymous with terms such
as "triggers" or "link indications" used in other documents.
Similarly, the term "link layer connection" is
used, which may or may not correspond to the term
"link up" used in this and other documents.

c. Normative language is used relating to events without
a tie to the DNA spec.  For example, the document requires
that "link down" events be generated prior to a "link up" without
indicating why such events would be helpful.  In fact, in DNAv4 these
events will be ignored, and generating such events would actually be
harmful to operating systems or applications that tear down connections on
receipt of "link down" events.

Abstract:

"  Certain network access technologies are capable of providing various
    link-layer status information to IP.  Link-layer event notifications
    can help IP expeditiously detect configuration changes.  This
    document provides a non-exhaustive catalogue of information available
    from well-known access technologies."

This abstract does not clearly indicate the purpose of the document.  It
would be helpful to state that the primary purpose is to address
events relating to DNAv6 (since the document does not appear to apply to
DNAv4).

Section 1

"  Detecting the subnet change can usually use
    network-layer indications such as a change in the advertised prefixes
    (i.e., appearance and disappearance of prefixes)."

Is this document solely focussed on DNAv6? If IPv4 is in scope, then since
router advertisement is not widely implemented, it should be made clear
that prefixes are just an example. For example, you can change the text
to:

"  Detecting the subnet change can usually use
    network-layer indications (such as a change in the advertised
    prefixes for IPv6)."

   "Establishment and
    tear down of a link-layer connection are two basic events types.
    Additional information can be conveyed in addition to the event type,
    such as the identifier of the network attachment point (e.g., IEEE
    802.11 BSSID and SSID), or network-layer configuration parameters
    obtained via the link-layer attachment process if available.  It is
    envisaged that such event notifications can in certain circumstances
    be used to expedite the inter-subnet movement detection and
    reconfiguration process.  For example, the notification indicating
    that the node has established a new link-layer connection MAY be used
    for immediately probing the network for a possible configuration
    change.  In the absence of such a notification from the link-layer,
    IP has to wait for indications that are not immediately available,
    such as receipt of next scheduled router advertisement,
    unreachability of the default gateway, etc."

The term "link layer connection" is used here, but is not defined.
I am not sure whether this only relates to connection-oriented
link layers, or whether this is synonymous with "link up".

What are "network layer configuration parameters obtained via the
link-layer attachment process"?  Perhaps an example would help (e.g. PPP
IPCP)

"   Two basic link-layer events are considered potentially useful to DNA
    process: link up and link down."

This contradicts RFC 4436, Section 1.3:
"DNAv4 does not utilize "Link Down" indications."

   "Each time the interface changes its point of attachment, a
    link down event with the previous attachment point MUST be followed
    by a link up event with the new one.  Finally, when the network
    interface is disabled, this MUST generate a link down event.  Each
    one of these events MUST generate a notification in the order they
    occur."

I don't understand the use of normative language here.  Given that
link down is not used by DNAv4, why is it relevant to require that
link down events be generated on handoff?  Existing operating systems
do not necessarily generate these events because they can be disruptive
to applications.

    "While
    merely knowing that a new link-layer connection is established may
    prompt DNA process to immediately seek other clues for detecting
    network configuration change, auxiliary information may constitute
    further clues (and even the final answers sometimes)."

DNAv4 does not utilize link-layer information this way.   Rather than
utilizing link-layer "hints", in DNAv4, all the active configurations
are probed via ARP.

Section 2.3

   "A station (STA) MUST establish
    a IEEE 802.11 link with an AP in order to send and receive IP
    packets."

I'm not clear why the term "link" is used here (I think this refers to
Association) or why it is normative (presumably the ability to send
data frames is determined by the 802.11 specification, not this document).

"  BSSID and SSID MUST be provided as auxiliary information
    along with the link up notification.  Unfortunately this information
    does not provide a deterministic indication of whether the IP-layer
    configuration MUST be changed upon movement."

Given the limitations of the BSSID and SSID, why the
normative language?  DNAv4 implementations will not use this
information.

   "If authentication is performed, a link up indication can be
    generated upon authentication, and a link down indication can be
    generated upon deauthentication."

What if authentication is not performed?  How are "link up"
and "link down" determined?

Section 2.4.2

"   Ethernet networks commonly consist of LANs joined together by
    transparent bridges (usually implemented as switches).  Transparent
    bridges require the active topology to be loop free.  The Spanning
    Tree Protocol (STP) achieves this by the exchange of Bridge Protocol
    Data Unit (BPDU), as defined in [IEEE-802.1D], which leads to, where
    required, the blocking of ports (i.e., not forwarding)."

I think you need to mention RSTP here as well.

"   Most hosts today do not listen to BPDU frames.  For these hosts,
    connectivity to the a port which is potentially bridged (any Ethernet
    port) carries the potential of frame loss if transmissions occur
    before any bridges' ForwardDelay timers have expired twice."

"to the a port" - "to the port"

"   If no bridge configuration messages are received within the
    Bridge_Max_Age interval (default 20s), then it is likely that there
    is no visible bridge whose port is enabled for bridging (S8.4.5 of
    [IEEE-802.1D]), since at least two BPDU hello messages would have
    been lost.  Upon this timeout, a link up notification MUST be
    generated.

    It is not easy for a non-STP host to distinguish between Disabled
    bridge ports and non-bridge ports with no IP nodes on them, as
    Disabled ports will have no traffic on them, and incur 100% sender
    loss.

    Upon this Bridge_Max_Age timeout, a link up notification must be
    generated.  If an earlier link up was generated with the R-flag set,
    this new one MUST set the A-flag showing that packets sent within the
    prior interval were likely to have traversed the forwarding path
    (unless the port is disabled)."

The next section talks about when to enable the delay, but I think you
could be more clear about this here as well.  For example, are you
recommending that hosts listen for STP/RSTP messages, or use 802.1AB
in order to decide on the appropriate delay?  Delaying for 20 seconds
by default probably isn't a good idea now that RSTP is becoming more
common.

"  Due to the protocol's newness and lack of deployment, it is unclear
    how this protocol will eventually affect DNA in IPv4 or IPv6
    networks."

DNAv4 does not utilize 802.1AB "hints", so this could be clarified.

Section 2.4.4

"   Link-Layer indications in Ethernet-like networks are complicated by
    additional unadvertised delays due to Spanning Tree calculations.
    This may cause re-indication (link up with A-flag) or retraction
    (link up with B-flag) of indications previously sent to upper layer
    protocols."

What are the A and B flags?  Is this an artifact of a previous revision?

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 May 2006 16:47:38 +0300

FWIW, I agree with most of Bernard's comments. Some further
discussion below:

> number of statements that do not reflect the operation of DNAv4 as
> defined in RFC 4436.  For example, DNAv4 does not utilize "link down"
> events or make use of link layer "hints".

> events relating to DNAv6 (since the document does not appear to apply to

If we take a strict interpretation of the charter, the DNA WG is
only chartered to look at IPv6. Having said that, a version
agnostic document would in my opinion be useful, assuming
we could make it acceptable. I'm not sure why there would
be a need for the v4 and v6 case to differ much, since *this*
document should not describe the actual DNA process -- just
input for the process, such as the "link up" event.

Also, I can not see where the "link down" event is used
even in DNAv6 -- draft-ietf-dna-protocol uses "link up"
only, just as DNAv4. But is it used somewhere else? If
not, perhaps the right thing to do is to focus only on the
"link up" in this document.

> normative language?  DNAv4 implementations will not use this

I agree that the BSSID and SSID may be of limited value. If they
are needed, at least MUST seems inappropriate.

> What are the A and B flags?  Is this an artifact of a previous revision?

Defined earlier in Section 2.

Anyway, I have a question for you Bernard: draft-iab-link-indications
talks about the importance of damping and hysterisis -- has that
been sufficiently addressed in the wireless parts of the
dna-link-information document?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 May 2006 10:52:59 -0700

>dna-link-information document?

Damping & hystersis need to be addressed in the DNA specifications 
themselves, so that DNA can be immune to driver malfunctions.  As an 
example, RFC 4436 rate limits DNAv4 exchanges, so that a jittering driver 
would not cause a flood of DNAv4 probes.

I do think this document creates a problem by mandating that a "link down" 
event be sent on each handoff.  It is possible for a handoff to occur with 
minimal connectivity loss, so that the link was never "down", at least not 
long enough for an application to care about it.  Requiring "link down" 
events will cause harm in situations where the TCP stack or applications 
tear down connections on receipt of a "link down".   Because of the downside 
to sending a "link down" event, these events are often damped, and if a 
"link up" occurs prior to expiration of the damping timer, then a "link 
down" event may not be sent.

---

From: James Kempf <[email-masked]>
Date: Tue, 23 May 2006 22:29:10 -0700

I believe the DNAv6 protocol spec says that RS probes occur upon a hint from 
L2 that the link has changed. The nature of the hint is left as an exercise 
to the implementor, and may, in fact, be quite different depending on the 
nature of the L2 protocol. Is that acceptable?

Regarding jitter, I don't recall whether that is dealt with on the host side 
in DNAv6, but there is an extensive discussion of a token bucket algorithm 
on the router to protect the routers and other hosts on the link against 
flooding. IHO, regardless of what the spec says about the host side, 
someobody could always hack the driver to flood the link. The DT was 
primarily concerned with protecting against such attacks, but I suppose it 
might be appropriate to include some text in the spec to protect against 
malfunctions as well.

            jak

----- Original Message ----- 
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 23, 2006 10:52 AM
Subject: Re: [DNA] Review of draft-ietf-dna-link-information-03.txt

> tear down connections on receipt of a "link down".   Because of the 
> downside to sending a "link down" event, these events are often damped, 
> and if a "link up" occurs prior to expiration of the damping timer, then a 
> "link down" event may not be sent.
>
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 May 2006 06:27:27 -0700

>I believe the DNAv6 protocol spec says that RS probes occur upon a hint 
>from L2 that the link has changed. The nature of the hint is left as an 
>exercise to the implementor, and may, in fact, be quite different depending 
>on the nature of the L2 protocol. Is that acceptable?

Since it doesn't make sense to send out RS probes on a "Link Down" 
indication, or as the result of events such as rate negotiation, I assume 
that "changed" means "Link Up", no?

>IHO, regardless of what the spec says about the host side, somebody could 
>always hack the driver to flood the link. The DT was primarily concerned 
>with protecting against such attacks, but I suppose it might be appropriate 
>to include some text in the spec to protect against malfunctions as well.

The issue isn't so much DoS (since as you point out, attacks don't have to 
implement the spec), as protecting against malfunctioning drivers.  For 
example, I have seen drivers that don't damp "Link Up" and so it is possible 
to receive ~10 indications per second in some circumstances.   If a number 
of hosts all had the same problem (e.g. if such a malfunctioning driver made 
its way into a mass-market handset), DNA implementations without built-in 
damping could cause serious problems.

---

From: James Kempf <[email-masked]>
Date: Wed, 24 May 2006 06:47:14 -0700

>>with protecting against such attacks, but I suppose it might be 
>>appropriate to include some text in the spec to protect against 
>>malfunctions as well.
>

Yes.

> example, I have seen drivers that don't damp "Link Up" and so it is 
> possible to receive ~10 indications per second in some circumstances.   If 
> a number of hosts all had the same problem (e.g. if such a malfunctioning 
> driver made its way into a mass-market handset), DNA implementations 
> without built-in damping could cause serious problems.
>

Certainly from the host side that is true.

            jak