[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
isp-cases-02 comments
Hello,
First, it seems that some/many of my earlier comments:
Date: Wed, 18 Sep 2002 18:25:58 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: Cleve Mickles <micklesc@aol.net>
Cc: v6ops@ops.ietf.org
Subject: ISP scenarios comments
haven't been integrated or commented on. Frustrating.
As for the other issues that struct me while reading..
Substantial:
3.1.3.4.....Multicast
Multicast is not widely deployed in CORE networks. To implement multicast,
providers have deployed parallel infrastructure using Unix hosts running
mboned or dvmrp on separate routers.
==> I don't know which providers (today) do that, but all I know either
don't do multicast at all, or do it using PIM.
3.1.4. Traffic Engineering
==> advertisements between and inside ISP's today are also TE (some of
them are multihoming, of course). There may be a problem with this if
certain policies disallow more specifics.
3.1.5.2.....Ingress Filtering
==> note that ingress filtering can also be implemented as static access
lists, not just as uRPF.
Cable modems use a combination of policy settings and IGMPv2[RFC2236]
to control multicast forwarding (see Section 3.3.1 [DOCSIS-1.1]).
Forwarding of IPv6 multicast datagrams may not occur properly as CMs
are required to forward multicast datagrams only when CPE equipment
has joined that group. This is potentially a show-stopper if native
IPv6 Neighbor Discovery[RFC2461] is being used through a CM.
==> this may or may not be related to the multicast problems presented at
draft-savola-v6ops-multicast-issues-01. If not, I'd like to hear comments
from people more familiar with the inner workings cable modems.
3.2.4. HFC IPv6 Deployment Options
==> some of these might be (to some degree of detail) better off in the
yet-to-come solutions document.
3.2.8 Network Management
DOCSIS cable modems use an out of band, privately addressed IPv4
network for configuration and network management functions.
==> I don't really know DOCSIS, but is it _really_ out-of-band? How is it
separated from the rest of the traffic?
3.4.6. Network Management
[dialup]
==> especially in dial-up, the ISP usually collects some info like userid,
IP address, time connected, etc. for accounting purposes. These
accounting tools may need to support v6 addresses too.
3.6.1.1 Physical architecture of public wireless LAN
Public wireless LAN (WLAN) enables subscribers within home, office or the
outdo
Figure 3.6.1 describes the physical architecture of wireless LAN model.
+-------+
| AAA |
| Radius|
| TACACS|
'---' +-------+
( ) |
+-----+ (Wireless) +----+ /------------\ +-------+
|Hosts+--( LAN )---| AP |----| Underlying \--- | ISP |==> Core
+-----+ ( ) +----+ \ technology | | Edge |
( ) \-----------/ | Router|
'---' +-------+
==> isn't this a simplification? Where's the access router here? Are
these routed/bridged connections? (1 AP/subnet or possibly many
APs/subnet)
==> in bridged case, may have v6-specific considerations.
Like ethernet, IEEE 802.11 standard dose not define authentication and
security
mechanisms. Moreover, WLAN is basically a broadcast network and each host
can l
two authentication mechanisms: (1) IEEE 802.1x and (2) non-standard MAC
address
based authentication.
==> I believe there are many other ways to build WLAN's that using these
two authentication techniques (e.g. some web hijacking + auth).
3.6.4.1 IEEE 802.1x based authentication
IEEE 802.1x enables edge devices such as bridge or AP to perform
authentication mechanism, and determines whether to allow or block data
transmitted by hosts. It uses extended authentication protocol (EAP) as a
standard protocol to transmit subscriber's authentication data.
Authentication is based of userID and/or password, and packets transmitted
by un-authenticated hosts are filtered and dropped by AP Figure 3.6.3
describes logical architecture of 802.1x based authentication
==> I can't see how eavesdropping couldn't be used to cause MITM or steal
credentials, but I'm not sure if more detailed discussion of 802.1x
belongs here.
3.6.4.4 Intrusion Detection, Ingress Filtering, and Prevention
==> one particular point about WLAN's is that as they're usually more
widely available (think of "war-driving"), attempts for malicious activies
are more probably higher too -- there may have to be more monitoring
activities than other access methods usually.
Editorial:
==> the lines are way too long, the limit is 72 chars.
==> different scenarios under section 3 should really be their own
higher-level sections -- that would reduce the nesting a bit; listing all
the levels of requirements (IGP, EGP, ...) may not be usable in ToC, it
just makes it longer.
3.1.6.2.....Configuration Tools
Many ISPs have monitoring tools that query the network gear to gather data.
These scripts are written in perl or expect and will access the device via
the CLI over the in-band ipv4 connection.
==> not so definite, please (at least s/are written/may be written/)
A CMTS MAY also be an IPv6 router and thus support IPv6 natively.
==> should this special-uppercase keywording be a bit more restricted, to
cases it's really useful for -- the document is not meant to be
normative, I think -- s/MAY/may/ ?
Some small ISPs do not even provide global addresses to their customers.
These ISPs then operates NATs on their backbones.
==> s/operates/operate/
Once a subscriber is considered as valid, information
exchanged between AP
==> s/as// ?
--
Pekka Savola "Tell me of difficulties surmounted,
Netcore Oy not those you stumble over and fall"
Systems. Networks. Security. -- Robert Jordan: A Crown of Swords