On Sat, 19 Jan 2002, Francis Dupont wrote:
> There is a downside: destination site's filtering ("spoofing protection"
> from the direction of the Internet) is nullified!
>
> (This attack is especially nasty in "send an UDP exploit" scenarios -- not
> necessarily DoS.)
>
> => this is 4.1 section of my draft:
I know.
You're making assumptions here:
- every packet filter in the internet can
1) recognize HAO
2) parse it, and
3) match against the address in it
This does not hold *at all*. I doubt very much even a half of IPv6 packet
filters, router access-lists etc. would do this in a few years' time (look
how long it has taken to e.g. get anycast implemented, and to what
success..).
The easiest method, which *might* be deployable soonish would be a check
whether HAO exists or not (1) above), and drop all packets with it.
However, this would kill all the use for HAO too; not good enough.
Iff 3) above holds, every site which does not have mobile nodes of its own
can be protected. (If it has MN's, state/AAA or more lax security for the
addresses is required.)
In my opinion, this is an unrealistic requirement.
> - the vulnerability can exist *only* if there are some home agents
> inside the site (this is a strong constraint)
> - the defense is basically the same: the filtering devices have to
> know the bindings (the home registrations are enough) by the way
> you'd like (several work, the only implementation I know uses
> BU/BA snooping with success).
>
> This can be more or less partially repaired, by e.g. allow incoming HAO
> with local Home Address only from local MN's, or local MN's that are known
> to be outside, or even local MN's that match a specific binding and are
> outside.
>
> => no, this can be fully repaired. And in most cases very easily:
> no home agent = no binding = just apply the anti-spoofing to everything
> that can be a source address.
See above.
> However, for security, that requires packet filters wanting to protect
> from this must have the ability to go into extension headers and match
> against HAO..
>
> => if your packet filter doesn't already do that, change it ASAP.
I don't know of any alternative.
> this is not yet implemented anywhere that I know of;
>
> => this was implemented 30 months ago somewhere I know of.
> (I can ask for a testimony if you really want it)
I'm interested, sure.
But really, I'm not all that interested if it was implemented just
somewhere and not integrated with any firewalling products.
> requiring this for security of HAO might be too much.
>
> => if I apply your argument to the routing header it should be forbidden...
> I strongly disagree: stupid defects in some stupid firewalls should not
> be admissible arguments against a protocol feature.
Perhaps, perhaps not. But I was not advocating Routing Headers be
filtered in firewalls; I was not advocating HAO be either (because both
are difficult problems which I think will not be deployed in the real
world very widely).
Instead, I was advocating stronger checks in the end-nodes, thus
eliminating the need for firewall security checks except for those 1% who
really want to go and build the AAA system to get the extra control and
security. For routing headers, it appears this issue will be clarified.
For HAO, this is still open as it would require bigger modifications.
> PS: the position of the HAO in packets was required by some firewall people,
> so I believe there are at least two firewall expert teams which already
> managed how to deal with HAOs...
Wrong assumption. This means some firewall people have analyzed what it
seems to be required to manage HAO at all: whether it can be checked under
every circumstance (e.g. IPSEC secured data) and where it is usually
located (check for the existance of the header, not necessarily the
content). This speaks nothing for implementing parsing for it, or
anything.
--
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
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
