a couple of high-view questions

Hi Pekka,

> 
> Triggered by the discussion at int-area list, I read
the 
> threats, ps and req documents on a flight.  I have a
number 
> of comments, but I'd like to make a couple of
high-level 
> observations and questions first:
> 
> [[ by the way, the UTF-8 messages from the issue
tracker 
> aren't in text format in the archive.. which makes
checking 
> the archives a bit painful... ]]
> 
> - multicast MUST work from day one.  It's simply
unacceptable 
> to devise a protocol which would break multicast.
> 

Agree that it would be unacceptable if multicast is actually
'broken'. I
am hoping that by deferring multicast support, the charter
only means
deferring "native" multicast support. I expect
multicast to work
inefficiently (for instance, multicast-in-unicast tunnels).
If the DT
produces a protocol that breaks multicast, that would be
unacceptable.  

> - the analysis of routing protocol usage seems to be
based on 
> misunderstanding of the capabilities of routing
protocols. 
> The aggregator router(s) can have an aggregate route
for all 
> the prefixes (+ more specifics from all the MNs), each
access 
> router is an OSPF stub area (or similar in IS-IS) of
its own, 
> and gets only a default route.  If there can't be a
direct 
> link between the aggregation
> router(s) and the access router, a routing protocol can
be 
> run on a tunnel interface.
> 
> So, it seems you may be re-inventing OSPF + stub areas
(or 
> similar approach with other routing protocols) running
on top 
> of tunnels (for AR <-> MAP information
distribution).  Some 
> other parts of the protocol, such as the AR<->MN
interface 
> would still be needed, though.
> 

The recent discussions on the protocol are leading me to the
same
concerns. I thought I had an understanding of how this
protocol is going
to work, but I am not so sure any more  I have
decided to wait for the
DT document at this point - but, nevertheless, I'm
concerned about the
use of host routes (these have proven to be a bad idea for
mobility
management in the past and we have abandoned protocols that
have
proposed that). I'll have to wait for the protocol document
to see if my
concerns are misplaced.  

> - how are access routers envisioned to forward
inter-subnet 
> traffic with global addresses?  Do they have to perform

> proxy-ND or bridging? 
> Note that the you should study Dave Thaler's 'issues
with 
> multi-link subnets' document/presentation (intarea at
IETF65) here...
> 

Yes, I think the WG largely is aware of this. I'm hoping
that the
behavior needed to address this will be specified in the
protocol
specification. 

> - is it required that all the subnet's traffic between
ARs 
> goes through MAP, i.e., a single point(s) of failure? 
I'd 
> guess this is the flip side of the
"scalability" coin..
> 

As Henrik said, currently, yes. 

> - I'd like to note that as the size of the subnet
increases 
> dramatically, the threat of attacks from inside the
subnet 
> increases as well.  Similar applies to TRILL WG as
well.  
> NETLMM seems to make this issue worse because by
re-using 
> someone else's identifier (MAC address?), you'll be
able to 
> hijack, MITM or DoS the traffic.  Hence, the threats
document 
> needs to be MUCH more explicit about the threats to the
MN 
> identifier mapping... and these problems actually NEED
to be 
> addressed as well.
> 

In Dallas, we were told that the threats on the protocol
itself will be
addressed by the document produced by the DT (the current
threats
document only covers the MN-AR interface). Extended ND
threats are
definitely a major problem. Also, another issue is that a
compromised AR
can now redirect the traffic meant for any MN in the NETLMM
domain on to
itself - essentially, the effect of a compromised AR is no
longer
limited to its link and that could be a big problem as well.
I'd like to
see the protocol document cover all of these points in depth
- I think
addressing these are essential to have a robust protocol. 

Regards,
Vidya

> -- 
> 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
> netlmmngnet.it
> https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm
> 

_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm