RE: isp-cases-02 comments

["MicklesCK" <micklesck@aol.com>]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

See my comments "in line" below.  A new draft
was submitted with those changes and a few others.

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
> Behalf Of Pekka Savola
> Sent: Sunday, November 17, 2002 6:08 PM
> To: v6ops@ops.ietf.org
> Subject: 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.

Added a reference to reflect the recommended solution for Multicast
is PIM-SM.

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

I'm not sure how to change the verbiage here.  I can remove the
reference but some ISPs do fiddle( not recommended ) with
advertisements to perform TE.

> 3.1.5.2.....Ingress Filtering
>
> ==> note that ingress filtering can also be implemented as static access
> lists, not just as uRPF.
>

Added the note about static filtering.

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

Agreed.  Section was removed from the scenario 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.
>

Added the note.

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

Fixed.


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

Adjusted the numbering and removed the nested levels from
the TOC.

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

changed.

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

corrected.

>
>    Some small ISPs do not even provide global addresses to their
> customers.  These ISPs then operates NATs on their backbones.
>
> ==> s/operates/operate/

corrected.

>
>  Once a subscriber is considered as valid, information
> exchanged between AP
>
> ==> s/as// ?

...not sure what the previous comment means?

Thanks,

Cleve...

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