Hi,
Some comments about the main body of req doc below.
substantial
-----------
1) section 2 rules out of scope from initial goals
discussion "QoS,
multicast, and dormant mode/paging". Is it the
intention that these
will appear in future revisions of the goals I-D, or
that they will be
out of scope? I don't care myself so much about the
other two, but
multicast must continue to work without modifications
in NetLMM domain.
I'm not sure what the requirements actually are -- it
might be OK that
link-local multicast need not be forwarded out of the
link, but global or
site-scoped multicast should work at the very least.
2) section 2.1 discusses handover performance improvement,
but also
mentions ".. and the delay required for active IP
layer movement detection".
I think it would be very useful to try to put at least
a ballpark figure
of additional delays here. Are we talking about 50,
500 or 5000
milliseconds? How does that vary depending on whether
DNA (or which
part of DNA) is implemented?
3) section 2.2: I guess the assumption is that the global
address DAD guarantees
uniqueness within the subnet already, though DAD will
definitely be required
the first time the MN attaches to the NetLMM domain. It
might also be
required when moving from link-to-link if the connectivity
is not maintained
or the address defended while the node is away. However, a
more
questionable topic is DAD for the link-local address. Is
that unique within
the NetLMM domain, or just the link? Does that cause
additional delay.
Point 4) does not discuss this.
4) section 2.3 discusses the threat where the MN (or
malware at MN) could
reveal information such as IP address which would
compomise privacy. I
don't think it makes sense to go there here: that's
a much much more generic
problem, and I'd say that revealing a care-of IP
address is the LEAST of
your privacy worries if you're infected with malware.
5) the 2nd paragraph of section 2.6 describes that
removing MN involvement
in LMM limits the DoS attacks on network
infrastructural elements.
Like privacy, this is a much more generic problem, and
I don't think
this is relevant to the requirements. It's easy to
find out those
infrastructure devices/addresses via other means, or
if not, just drop them
off the net with a big DDoS attack.
So, I'd completely remove any references to DoS
against infrastructure
from this section. The existing need of no further
security is good
enough as it is.
However, you may need to think a bit about what if MN
ID mapping
techniques / IP address configuration is not secure
enough as it is. Then
you WILL require "extra" (by some
definition) security, or run an insecure
network. Hence, in practice, at least in some
networks the additional
work of security the host-based LMM credentials and
securing the MN ID
mapping might end up being be equal.
6) I didn't read the appendix except for section 9.5, and
it has the same
issues which were already brought up earlier. There's also
no discussion of
combined IGP/BGP + a tunnel.
semi-editorial
--------------
If link layer support exists for IP level movement
detection, the
mobile node may not need to perform any additional IP
level signaling after
handover.
==> does this kind of support exist anywhere? Is it good
enough?
While header compression technology can remove header
overhead, header
compression does not come without cost. Requiring
header compression on the
wireless access points increases the cost and
complexity of the access
points, and increases the amount of processing
required for traffic across
the wireless link.
==> doesn't HC require any software on the host? You
don't mention that
factor at all..
While bandwidth and router processing resources are
typically not as
constrained in the wired network, wired networks tend
to have higher
bandwidth and router processing constraints than
the backbone.
==> It took a little time to understand what I think you
were saying here,
rewording would help.. (hint: backbone networks are also
wired networks 
editorial
---------
==> one author too many..
==> In some cases, you've used "routing"
where a better word would have been
"forwarding".
==> AFAIR, "router certificate" was not the
exact term SEND spec used..
and this process typically requires that the IP
stack for the new interface card be configured on the
mobile node from the
driver up.
==> remove "up" earlier in the sentence..?
--
Pekka Savola "You each name yourselves
king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash
of Kings
_______________________________________________
netlmm mailing list
netlmm ngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
|