Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
draft-irtf-mobopts-l2-abstractions-07

[Ballot comment]
This document points to iab-link-indications as the basis for the its brief security
considerations, but I am not convinced that the points raised in that document
were adequately addressed.

For example, iab-link-indications notes for spoofing attacks:

  However, even where the link layer incorporates security, attacks may
  still be possible if the security model is not consistent.

yet this document addresses spoofing with a single sentence:

"Our proposal is nor more insecure than a particular link layer on which it is
implemented"

These statements appear to be a contradiction.  I believe that the treatment of spoofing
and denial of service should be expanded in the security considerations section to clearly
demonstrate the issues raised in iab-link-indications have been fully addressed.

[Ballot comment]
1. The issue is partially dealt with in Tim's DISCUSS. It is not clear to me whether the following statement made twice in the Security Considerations section is sufficient:

> Our proposal is nor more insecure than a particular link layer on which it is implemented

The proposal is for signaling between L2 and L3. If so, why does this phrase make mention of the particular link layer?

Note that if indeed we are dealing with threats for signalling transported over a link layer there are sufficient reasons of concern and the simple reference to RFC 4907 may not be enough. In fact link layer security is ensured by mechanisms like IEEE 802.1AE and these should be explictly refered.

2. Should this document result into IETF standards track work I would have questions about the usage or some link layer specific terms. For example I am not sure whether the LinkUp and LinkDown terms are aligned with the RFC 2863 terminology. At this phase, this being an RFC Editor track Informational document I will not insist.

[Ballot discuss]
This document points to iab-link-indications as the basis for the its brief security
considerations, but I am not convinced that the points raised in that document
were adequately addressed.

For example, iab-link-indications notes for spoofing attacks:

  However, even where the link layer incorporates security, attacks may
  still be possible if the security model is not consistent.

yet this document addresses spoofing with a single sentence:

"Our proposal is nor more insecure than a particular link layer on which it is
implemented"

These statements appear to be a contradiction.  I believe that the treatment of spoofing
and denial of service should be expanded in the security considerations section to clearly
demonstrate the issues raised in iab-link-indications have been fully addressed.

[Ballot discuss]
This document points to iab-link-indications as the basis for the its brief security
considerations, but I am not convinced that the points raised in that document
were adequately addressed.

For example, iab-link-indications notes for spoofing attacks:

  However, even where the link layer incorporates security, attacks may
  still be possible if the security model is not consistent.

yet this document addresses spoofing with a single sentence:

"Our proposal is nor more insecure than a particular link layer on which it is
implemented"

I believe that the treatment of spoofing and denial of service should be expanded
in the security considerations section.

[Ballot comment]
This document is mostly harmless, but also at least partially useless.

Some indications it defines go in the right direction (link up/down), but especially the stuff about link quality is so underdefined that it can't be used for anything: What should the stack do when link quality goes from GOOD to FAIR? What does that even mean? If my 802.11 link is FAIR but my 3G link is GOOD, do I hand over? Even for the link up/down indications, it isn't even clear if "link up" means if we have an IP address or not.

[Ballot comment]
I do not see a conflict with ongoing IETF work, though
discussion of similar additional information to help mobile
nodes has been happening in the DHC, DNA, and MIPSHOP
WGs, and in the IEEE 802.21 group. In addition, RFC
4957 was published about a subset of this interface
from the DNA WG.

Comments:

My personal opinion though is that the presented
interfaces are not very practical -- not that this
is a requirement for research work. So, further
work would be needed to actually use these in the
the real world or standardize them.

To be usable the interfaces would have to be substantially
more well specified. For instance, RFC 4957 focused
on one event for one purpose, and it turned out
that the interactions are far from trivial.

For instance, the document does not deal with the
intricacies related to what it means to be associated
with another wireless end point. For instance, on
802.11 having an association, having completed RSN,
and having an IP address are all different situations.

Nits:

The document would probably benefit from a reference
to RFC 4957.

Draft-iab-link-indications has been published as RFC 4907.

Author's name in [7] should be "Aboba", not "Adoba".

[Ballot comment]
I do not see a conflict with ongoing IETF work, though
discussion of additional information to help mobile
nodes has been happening in the DHC, DNA, and MIPSHOP
WGs, and in the IEEE 802.21 group. In addition, RFC
4957 was published about a subset of this problem
from the DNA WG.

Comments:

My personal opinion though is that the presented
interfaces are not very practical -- not that this
is a requirement for research work. To be usable
the interfaces would have to be substantially more
well specified. For instance, RFC 4957 focused
on one event for one purpose, and it turned out
that the interactions are far from trivial.

For instance, the document does not deal with the
intricacies related to what it means to be associated
with another wireless end point. For instance, on
802.11 having an association, having completed RSN,
and having an IP address are all different situations.

Nits:

The document would probably benefit from a reference
to RFC 4957.

Draft-iab-link-indications has been published as RFC 4907.

Author's name in [7] should be "Aboba", not "Adoba".

[Ballot comment]
I do not see a conflict with ongoing IETF work, though
discussion of additional information to help mobile
nodes has been happening in the DHC, DNA, and MIPSHOP
WGs, and in the IEEE 802.21 group. In addition, RFC
4957 was published about a subset of this problem
from the DNA WG.

Comments:

My personal opinion though is that the presented
interfaces are not very practical -- not that this
is a requirement for research work. To be usable
the interfaces would have to be substantially more
well specified. For instance, RFC 4957 focused
on one event for one purpose, and it turned out
that the interactions are far from trivial.

For instance, the document does not deal with the
intricacies related to what it means to be associated
with another wireless end point. For instance, on
802.11 having an association, having completed RSN,
and having an IP address are all different situations.

Nits:

The document would probably benefit from a reference
to RFC 4957.

Draft-iab-link-indications has been published as RFC 4907.

[Ballot comment]
I do not see a conflict with ongoing IETF work, though
discussion of additional information to help mobile
nodes has been happening in the DHC, DNA, and MIPSHOP
WGs, and in the IEEE 802.21 group. In addition, RFC
4957 was published about a subset of this problem
from the DNA WG.

Comments:

My personal opinion though is that the presented
interfaces are not very practical -- not that this
is a requirement for research work. To be usable
the interfaces would have to be substantially more
well specified. For instance, RFC 4957 focused
on one event for one purpose, and it turned out
that the interactions are far from trivial.

For instance, the document does not deal with the
intricacies related to what it means to be associated
with another wireless end point. For instance, on
802.11 having an association, having completed RSN,
and having an IP address are all different situations.

Nits:

Draft-iab-link-indications has been published as RFC 4907.

[Ballot comment]
I do not see a conflict with ongoing IETF work, though
discussion of additional information to help mobile
nodes has been happening in the DHC, DNA, and MIPSHOP
WGs, and in the IEEE 802.21 group. In addition, RFC
4957 was published about a subset of this problem
from the DNA WG.

My personal opinion though is that the presented
interfaces are not very practical -- not that this
is a requirement for research work. To be usable
the interfaces would have to be substantially more
well specified. For instance, RFC 4957 focused
on one event for one purpose, and it turned out
that the interactions are far from trivial.

Nits:

Draft-iab-link-indications has been published as RFC 4907.