a couple of high-view questions

Hi,

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.

- 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.

- 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...

- 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..

- 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.

-- 
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

Hi Pekka,

on 2006-05-15 13:28 Pekka Savola said the following:
> Hi,
> 
> 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.

Noted.  I believe you're right.

> - 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.

Very interesting.  This makes me thing that we should have
someone
who's seriously knowledgeable in routing and routing
protocols on
the design team, to balance the current set of mobility
people...

> - 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...
> 
> - 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..

For now, the assumption is yes.  The charter mentions future
work on
route optimization.  I see more optimal routing of
intra-subnet traffic
as one aspect of that.

> - 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.

I agree.  Speaking only for myself, I've been assuming in
the design
team work that relying on any un-authenticated identifier is
out, should
not be done.  

How strongly NetLMM should enforce this is related to the
range of
deployment scenarios to which it will be applied, I think -
should we
provide for deployment in a small cluster of WiFi nodes
where mandatory
identity authentication may be sufficiently onerous that it
won't be done?


	Henrik

Hi Pekka,

  Responding to the tool-related comment only in this
message:

on 2006-05-15 13:28 Pekka Savola said the following:
> Hi,
> 
> 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... ]]

Yes.  Once I was alerted to the fact that the issue tracker
was sending
out this format (by Thomas Narten) I changed it, so it
should now send
out non-base64-encoded ascii, and not use multipart
messages.  Sorry.


	Henrik

Pekka,

For a slightly different perspective on this problem
space, please have look at:

<<http://www.ietf.org/internet-drafts/draft-
templin-autoconf-netlmm-dhcp
-00.txt>>

Some responses to your specific points are included below:

> - multicast MUST work from day one.  It's simply
unacceptable to 
> devise a protocol which would break multicast.

OK. One possibility is to have the LMAs (was: MAPs)
perform a MARS-like function.

> - 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),

Agreed on the aggregator having aggregated routes + more
specifics.

> 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.

Agreed about the tunnel interface, but I'm not sure I quite
understand the OSPF stub area consideration. When a MN moves
to a new AR, are you thinking it would retain its IP address
or would it have to configure a new IP address relative to
its new AR? If the former, then wouldn't the MN have to
participate in the routing protocol?

> 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.
> 
> - 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...

For multi-link subnet considerations, please see Section 5.5
of:

<<http://www.ietf.org/internet-drafts/draft-
templin-autoconf-netlmm-dhcp
-00.txt>>

> - 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..

If the LMA (MAP) function can be distributed, then the
tradeoff
between scalability and fault tolerance can be fine-tuned.

Fred
fred.l.templinboeing.com

> - 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.
> 
> -- 
> 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

On Mon, 15 May 2006, Templin, Fred L wrote:
>> 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.
>
> Agreed about the tunnel interface, but I'm not sure I
quite
> understand the OSPF stub area consideration. When a MN
moves
> to a new AR, are you thinking it would retain its IP
address
> or would it have to configure a new IP address relative
to
> its new AR? If the former, then wouldn't the MN have
to
> participate in the routing protocol?

I was assuming the former.  Stub areas is just a way to
restrict OSPF 
flooding, i.e., eliminate the scalability concern voiced in
the past.

Yes, it will require additional mechanisms at ARs to map
host 
identifier detection to OSPF route update, i.e., send a
routing update 
packet as soon as they figure out (using whatever means)
that a new IP 
address X has joined the link -- but if there's supposed to
be no 
software at the host, this function needs to be implemented
in any 
case.

-- 
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

Pekka Savola wrote:
> On Mon, 15 May 2006, Templin, Fred L wrote:
>>> 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.
>> 
>> Agreed about the tunnel interface, but I'm not
sure I quite 
>> understand the OSPF stub area consideration. When a
MN moves to a 
>> new AR, are you thinking it would retain its IP
address or would it
>>  have to configure a new IP address relative to its
new AR? If the
>>  former, then wouldn't the MN have to participate
in the routing 
>> protocol?
> 
> I was assuming the former.  Stub areas is just a way to
restrict OSPF
>  flooding, i.e., eliminate the scalability concern
voiced in the 
> past.
> 
> Yes, it will require additional mechanisms at ARs to
map host 
> identifier detection to OSPF route update, i.e., send a
routing 
> update packet as soon as they figure out (using
whatever means) that
>  a new IP address X has joined the link

A means could be DHCP.  The mobile normally exchanges
DISCOVER/OFFER/REQ/ACK upon first attachment. On handover it
would only
send CONFIRM, keep same IP address.  CONFIRM could be used
by both Relay
and Server to send the updates.  It's just one way of using
DHCP.

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

On Tue, 16 May 2006, Alexandru Petrescu wrote:
> A means could be DHCP.  The mobile normally exchanges
> DISCOVER/OFFER/REQ/ACK upon first attachment. On
handover it would only
> send CONFIRM, keep same IP address.  CONFIRM could be
used by both Relay
> and Server to send the updates.  It's just one way of
using DHCP.

OK, I'll bite: what about stateless address
autoconfiguration?

DNA is (possibly) already one additional required piece of
software at 
the host.  Are you requiring DHCPv6 as well?

-- 
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

Pekka Savola wrote:
> On Tue, 16 May 2006, Alexandru Petrescu wrote:
>> A means could be DHCP.  The mobile normally
exchanges 
>> DISCOVER/OFFER/REQ/ACK upon first attachment. On
handover it would 
>> only send CONFIRM, keep same IP address.  CONFIRM
could be used by 
>> both Relay and Server to send the updates.  It's
just one way of 
>> using DHCP.
> 
> OK, I'll bite: what about stateless address
autoconfiguration?

AFAICT, stateless auto-config using ND messaging is probably
addressed
by the MN-AR interface draft, with SeND.

> DNA is (possibly) already one additional required piece
of software 
> at the host.

I agree.  DNA behaviours could be specified for netlmm too.

I think using DHCPv6 for netlmm involves less modifications
on the
mobile (but more on Relay and Server) while DNA is still
additional
software to be added on AR and MN.  It's debatable.

> Are you requiring DHCPv6 as well?

Public DHCPv6 host interoperable implementations may exist
on a wider
scale (I believe) than DNA.

That's always been a question here - what's an unmodified
host.  Listing
the non-modified protocols MN runs has been avoided.

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

Thanks Pekka,

>> Agreed about the tunnel interface, but I'm not
sure I quite
>> understand the OSPF stub area consideration. When a
MN moves
>> to a new AR, are you thinking it would retain its
IP address
>> or would it have to configure a new IP address
relative to
>> its new AR? If the former, then wouldn't the MN
have to
>> participate in the routing protocol?
>
> I was assuming the former.  Stub areas is just a way to
restrict OSPF 
> flooding, i.e., eliminate the scalability concern
voiced in the past.

OK, but when a MN moves to a new AR, an update will still
have
to be sent to the MAP (LMA) - right? Were you thinking that
the
MN would send the update, or that the AR would send the
update
on behalf of the MN?

> Yes, it will require additional mechanisms at ARs to
map host 
> identifier detection to OSPF route update, i.e., send a
routing update

> packet as soon as they figure out (using whatever
means) that a new IP

> address X has joined the link -- but if there's
supposed to be no 
> software at the host, this function needs to be
implemented in any 
> case.

About mod's to the host, my understanding is that hosts
will need
to be modified to implement (at least) DNA and so the myth
of a
completely unmodified host is just that.

Fred
fred.l.templinboeing.com
 
-- 
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

> -----Original Message-----
> From: Pekka Savola [mailto:pekkasnetcore.fi] 
> Sent: Tuesday, May 16, 2006 5:19 AM
> To: Alexandru Petrescu
> Cc: Templin, Fred L; netlmmngnet.it
> Subject: Re: [netlmm] a couple of high-view questions
> 
>> On Tue, 16 May 2006, Alexandru Petrescu wrote:
>> A means could be DHCP.  The mobile normally
exchanges
>> DISCOVER/OFFER/REQ/ACK upon first attachment. On
handover it would
only
>> send CONFIRM, keep same IP address.  CONFIRM could
be used by both
Relay
>> and Server to send the updates.  It's just one way
of using DHCP.

Obviously, I agree.

> OK, I'll bite: what about stateless address
autoconfiguration?

Stateless can be used to (pre)configure tentative addresses
that can use, e.g., CGAs, privacy addresses, etc. The
tentative addresses are then registered with the DHCP
server and tested for uniqueness in the process. So, in
IPv6, the benefits of stateless and stateful can be
combined; see paragraphs 1 and 2 of Section 5.1 of:

http://www.ietf.org/internet-drafts/draf
t-templin-autoconf-netlmm-dhcp-0
0.txt 

> DNA is (possibly) already one additional required piece
of software at

> the host.

I have seen text that suggests that DNA will be required.

> Are you requiring DHCPv6 as well?

For IPv6, yes. But, support for IPv4 can also be realized
using DHCP and to my understanding DHCPv4 is widely used
and well understood in fielded deployments.

Fred
fred.l.templinboeing.com 

-- 
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