Re: draft-ietf-grip-isp-00.txt

[Tom Killalea <tomk@nwnet.net>]

>1) The starting point for this document was to give suggestions to
>   Internet users as to what they should expect from their ISPs.
>   You've expanded it into a much more detailed list, which is a
>   little two-edged.
>
>   On the plus side, it gives ISPs (and those thinking about becoming
>   ISPs) a very good list of things they need to think about. The second
>   paragraph of the abstract clearly says the document is aimed at ISPs,
>   and I agree that's what the Working Group is addressing.  
>
>   On the minus side, it's now too long and too complex for 'naive'
>   users.  Perhaps it would be good to include an 'end-users checklist'
>   as an appendix?  What do other people think about this?

In considering the audience for this draft I looked at 4 groups:

  1) ISPs

  2) people who make purchasing decisions for Internet services for an
     organisation, and the people at such organisations who take
     responsibility for site security

  3) end users at organisations

  4) end users at home, etc.

I decided to focus on 1 and 2, given that

  - those two groups should be able (with the hellp of this document) to
    speak the same language and discuss security expectations using a
    common framework and terms of reference

  - the interests of 3 should be represented by 2

  - people in group 4 have very different needs and speak a very
    different language, and  their interests should be better met by 
    the SSH WG and specifically
    ftp://ftp.ietf.org/internet-drafts/draft-ietf-ssh-users-03.txt

The checklist idea is certainly worthy of more discussion.

[snip]
>   seems to imply that SNMPv2 security is workable - which we know
[snip]

I realise (blush) that my comments on SNMPv2 were naive, motivated by
ignorance on my part rather than anything else (like extreme pessimism
about how many years it will take before this draft advances).

>3) Section 10.1: A sentence to explain why DNS lookups should not
>   be performed on web clients when they connect would be useful.

This, the SNMPv2 reference, access to routers, encrypted transactions 
and some other comments that I received and a bunch of typos have been 
fixed in the next version, which I hope to submit by the end of the 
month.

>4) Some of the issues already commented on (on this list) are clearly
>   hot topics, e.g. Source Address Filtering and Open Mail Relays.
>   One of the aims of the document is to prompt discussion (seems
>   to be effective, doesn't it!), but we're clearly not going to
>   get consensus on these things any time soon.  I think we should
>   summarise such issues, and make the point that they are unresolved
>   at the time the I-D is published as an RFC.

I'd like to hear more from people, but that sounds like a reasonable
approach.

To be honest I thought that

  - the line I took on Source Address Filtering accurately represented
    discussions that we've had in GRIP meetings, and that I've had
    privately with some people involved in GRIP

  - the line I took on Open Mail Relays wasn't very extreme, where
    extreme is defined as blocking all outbound connections to port 25
    at the customer's border router except by the customer's known 
    mail relays.

I'll point out that nothing I introduce in this draft uses 'MUST'.

Eventually I'd like to include something about the following:
  
  - web content loading, and distributed authoring

  - push technologies

  - firewalls

Thanks to those who've given feedback on this draft - keep the comments
coming.

Tom.
--
Tom Killalea   (425) 649-7417    NorthWestNet
               tomk@nwnet.net