[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security Expectations for Internet Service Providers to BCP



iesg review comment

----

From: Thomas Narten <narten@raleigh.ibm.com>

No problem with the overall content, but the document would appear to
benefit from some minor tweaking. (Randy: if you take this back to the
authors, cc me and I'll participate directly.)

>   other ISPs or CSIRTs, with law enforcement or with the press and

forward reference to CSIRT. Spell out here?

>    ISPs should 'SWIP' (Shared WhoIs Project) the address space that they
>    assign to their customers so that there is more specific contact
>    information for the delegated space.

a formal reference to SWIP would seem to be in order.

>    Due care should also be taken in determining in whose routing
>    announcements you place greater trust when a choice of routes are
>    available to a destination.  In the past bogus announcements have
>    resulted in traffic being 'black holed', or worse, hijacked.  BGP
>    authentication should be used with routing peers.

reference to BGP authentication document?

> 4.3 Ingress Filtering on Source Address

Should this document have some words about customer vs. ISP filtering,
i.e., who does the filtering and when? (This relates to an earlier
thread on the ingress filtering document itself). Perhaps not, given
that this document's focus is the ISP side.

>   The circumstances described in 5.7 in which ingress filtering isn't
>   feasible apply similarly to egress filtering.

no section 5.7. Does this actually refer to 2267?

> 4.6 Directed Broadcast
> 
>    The IP protocol allows for directed broadcast, the sending of a
>    packet across the network to be broadcast on to a specific subnet.
>    Very few practical uses for this feature exist, but several different
>    security attacks (primarily Denial of Service attacks making use of
>    the packet multiplication effect of the broadcast) use it.
>    Therefore, routers connected to a broadcast medium MUST NOT be
>    configured to allow directed broadcasts onto that medium [RFC2644].

MUST NOT seems too strong, and goes further than even 2644. Besides,
is it ISPs who are the favorite targets here, as opposed to end end
sites? I.e., end sites typically have more nodes attached to a given
segment than an ISP might and it's the number of responding nodes that
are the problem.

> 5.3 Open Mail Relay
> 
>    An SMTP mail server is said to be running as an 'open' mail relay if
>    it is willing to accept and relay to non-local destinations mail
>    messages that do not originate locally (i.e., neither the originator
>    nor the recipient address is local).  Such open relays are frequently
>    used by 'spammers' to inject their Unsolicited Bulk E-mail (UBE)
>    while hiding their identity.  There are only very limited
>    circumstances in which an administrator can make a justifiable case
>    for leaving a mail relay on the Internet completely open.

Actually, the above defintion seems slightly off. Isn't the real
problem mail servers that don't properly authenticate the party
sending the mail before accepting it? The "do not originate locally"
description doesn't accurately describe the problem.

Thomas