Re: Security Expectations for Internet Service Providers to BCP

[Bill Woodcock <woody@zocalo.net>]

This was an issue we discussed in Adelaide, I don't know if it's going to
be incorporated or not...  Basically that all discussion of filtering
contained the implicit but unstated assumption that directionality was
relative to the ISP (okay but should be stated), and there was no
discussion of the possiblity of customer-side filtering at all.  When the
CPE is under the ISP's exclusive  control, as is often the case,
customer-side actually works really well.

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

No question, I think the goal here is to encourage ISPs to set a good
example, even though they're not primary targets, and to understand the
problem and pass an understanding and spirit of activism along to their
customers, where the larger problem exists.  

The alternative, which I don't think anyone's very happy with, is to
suggest that ISPs filter known downstream broadcast addresses, within
their own infrastructure.  That, like ORBS or whatever, could wind up
making a fair chunk of address space unusable in perpetuity.  We do that
in instances where we know the customer has unprotected subnets, but we
try to avoid it, and the ACL bloat it causes is evil.  Taking that to 
access list foo deny ip any 0.0.0.255 255.255.255.0
access list foo deny ip any 0.0.0.0 255.255.255.0
across-the-board would blow away 0.8% of the usable address space out
there, even if it's not commonly used, without even solving the problem
for subnets smaller than /24.

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

Mmm, that assumes that [software and human] clients capable of doing
authentication exist in meaningful numbers, which I haven't observed,
perhaps through inattention. It also assumes that passwords would not be
exploited, et cetera, which opens quite a hole.  I agree in principle, but
without some practical sense of how feasible wide-scale authenticated
smtp deployment and support are, I'd be hesitant to push for including it
in a BCP.

                                -Bill