Re: I-D ACTION:draft-huitema-multi6-hosts-00.txt

[Pekka Savola <pekkas@netcore.fi>]

On Fri, 12 Oct 2001, Iljitsch van Beijnum wrote:
> On Fri, 12 Oct 2001, Pekka Savola wrote:
>
> > Here it's very much assumed that ingress filtering is only performed at
> > ISP-Customer border, by the ISP or possibly the site.  This is often the
> > case, but responsible sites (at least bigger sites) will do it internally
> > too, e.g. between different site sub-parts.  The strictest version of this
> > would be it being done in every LAN connection, by ACL's or with RPF
> > checks.
>
> That seems redundant. If you only accept valid addresses at the edges, how
> do packets with incorrect addresses get to the core?

If you forget to do proper filtering at one edge point, mistype the
command whatever, there's still some "safety net".  It's good to have
other kind of safeguards if you can.

> And aggressive
> filtering on source addresses is problematic with asymmetric routing,
> which is very common, so I would be surprised to hear that many ISPs do
> so.

This is not being done for two reasons (at least):

1) it cannot be done by ISP with (most implementations of?) uRPF, most
likely (your concern)
2) with IPv4, one big ISP may have hundreds/thousands of prefixes.  Too
big a list.  With IPv6, they might only have one or a few prefix(es) to
check.  Easy.

> > Additional checking could also be done elsewhere, e.g. isp-bigISP or
> > isp-transit border.
>
> :-)  Transit = default = the entire Internet = all packets from all
> sources are ok.

Transit, sure.  But consider tranit-ISP border.  ISP might want to check
that source addresses of packets going to transit match its prefix(es).

> > If this method would restrict the scope of applicability of ingress
> > filtering only to a few topological places ... doesn't sound good.
>
> If everybody filters at the edges that would be good enough. Many networks
> still don't.

Sure, but filtering at the edges can fail if you do it in the "core" too.
:-)

> > Another biggish issues that come to mind:
> >  - the reliance on DNS.
>
> This doesn't rely on the DNS any more than regular routing.

It relies on the DNS to get all the destination addresses.

That is, if DNS doesn't work, or the destination is in the IP numeric
form, and the destination networks other prefix is dead, you cannot talk
to the destination's other address, as you can't find it in the DNS.

The routing system itself doesn't rely on DNS, but hosts do.

> >  - if you get two addresses from DNS, one which is unreachable (e.g.
> > blackholed), how long does it _actually_ take to select the next one?
>
> >    this could take a _lot_ of time.  If you try a tcp connection to an
> > unanswering system, it's usually a _long_ time, in dozens of minutes in
> > most implementations I've seen.
>
> That is no good anyway. Do I have any use for a connection that is
> established after 119 seconds? Don't think so. One possible heuristic
> could be to expedite the timeout when there are still alternative
> addresses to try.

True.

> What concerns me more is that the draft talks about sending multiple SYN
> packets at the same time. Is SYN flooding an offense yet under the new
> anti-terrorist laws?

I agree that multiple SYN's should not be sent; other connections should
only be tried to be established after the first one fails.

Unfortunately I don't think e.g. socket api has ways to do this, ie.
specify that if the connection is not formed in 1sec, forget about it (or
retry); you would have to do it with application, e.g. with non-blocking
connect() and a timer.  That is, this appears to be generally a no-go.

> > ==> I do not see why 'incorrect source address' ICMP message _without the
> > accepted prefixes_ (which might be a security exposure, and difficult to
> > implement), would not be sufficient.  Usually a node would just have to
> > try one or two packets with different source addresses to find one that
> > matches.
>
> Also, doesn't the "ICMP administratively prohibited" message effectively
> accomplish this?

You could get administratively prohibited message for a lot of different
reasons; not necessarily a bad source address.  But I agree that at least
if one would like to test how this would work in practise,
administratively prohibited wouldn't be too far off the mark.

> > 4.4     Packet rewriting at exit router
>
> > ==> strong "eeevil!" on packet rewriting.  Would break ESP/HA too, I
> > suspect.
>
> There are worse things... Tunnels, for example.

Open-ended tunnels (that were referred to in the draft) are bad, but I
don't think configured p-t-p tunnels are always that bad.

> > ==> Tunneling is valid option but there is one additional problem:
> > increased requirement for Path MTU.  If node is already sending at the
> > full MTU discovered, adding extra bytes may be physically impossible
> > without fragmenting.
>
> - more packet overhead
> - endpoint creation problems
> - scenic routing
>
> The PMTU discovery shouldn't be a problem, since it is mandatory in IPv6
> so hopefully builders of stupid "security" products won't filter "packet
> too large" messages (or fail to generate them in the first place).

Should not be, yes.  I don't think if one packet sent lost by this would
be noticeable.  (host sends e.g. 1500B, 50ms away there is mtu 1480B,
first packet delivery delayed at least 150ms unless the path MTU was
cached).

> But on the subject of tunnels: I don't see how tunneling to a site exit
> router does any good. Sure, the packets get out when everything works, but
> the whole point is that your sessions survive when something goes down.
> This means every exit router should be able to send out valid packets
> without any help from other routers. So if the source address is
> inconvenient for a certain border router, it should do something about
> that (rewrite, ICMP) and not send the packet to another router.

I partially disagree.  The most important thing is the system to "plain
work".  If one can avoid short or even longer breaks by doing something
like tunneling, fine.

I wouldn't advocate tunneling as a solution for load-balancing or the like
though.  But under a more-or-less emergency situation, everything is
should be possible.

> > One way to work around this might be to set the MTU of interfaces where
> > you expect to do this so much lower that path MTU discovery will pick the
> > lower value and leave room for encapsulation.  Heavy to maintain.
>
> It's better set the MTU of the output interfaces HIGHER. Shouldn't be a
> problem unless your uplink is <= 100 Mbps ether.

Sure, so it would be better.  But that is not always physically possible.
And your clients could be connecting with POS, GE with jumbograms etc.
or something else with an equally high MTU as your uplink too.

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