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

Re: draft remarks

On 28-jun-04, at 9:45, Erik Nordmark wrote:

1.1 I think the assumption that an attacker can do everything is
dangerous, as this isn't a typical capability that an attacker would
have. It's much more common that an attacker can just monitor, or
monitor and inject but not block.

I don't have a problem adding a caveat about this in 1.1, but I'm trying
to understand the cases that you are thinking off.

Many networks and especially network elements such as switches today have monitoring facilities. Those work only in one direction, so inserting or blocking traffic can't be facilitated. Then there are wireless networks that are often easy to eavesdrop on. Maybe...

the attacker can also employ ARP/ND spoofing to get access to the packet flow which allows blocking as well.

I suppose. But hopefully SEND will do something about that...

2- ULP I think that the definition of ULP clashes with other uses of
the term, where it is used as "anything above the network layer" or
"anything above the layer under discussion". The current definition is
largely the same as "transport layer" if we ignore some more esoteric
protocols that run on top of IP (such as ICMP) which are special cases
with regard to multihoming anyway.

I see the definition has "immediately above IP" which actually wasn't the
intent. The intent was anything "above the network layer". If I say "any layer
above IP" and add some words about applications would that correct things?

IIRC, that is pretty much what it says now. My objection was that people use ULP more in the sense "anything above the layer under discussion", so your definition would be contrary to popular use.

Re 3.4: I think it would be possible to mitigate many of the problems
here by including a periodic state refresh and disallowing adding new
locators when the original address which has been "validated" using
return routability is no longer reachable.


I think preventing 3rd party flooding attacks doesn't have to be very
complicated. But are you proposing that a node could send to a locator
without having any assurance that the peer is in fact present at
that locator i.e. without any form of RR check?

No, that's not what I was saying. The trouble is that someone can redirect. Periodically refreshing state means that an attacker must impersonate the actual correspondent for a considerable amount of time rather than just fire off something quickly. Obviously when a rehoming event occurs this can no longer happen, so then we no longer allow new locators to be added to the originally negotiated set. At some point there is an RR check for all locators of course.

4.3 can be addressed by reflecting the original address back so if the
negotiation is corrupted by an attacker at least there is a way to
trace this back part of the way.

Are you commenting on the first paragraph of 4.3?

Not so much commenting on the text as discussing the issue.

The more specific details in 4.3.1 and 4.3.2 seems to indicate to me
that you actually need to verify that the peer is present at the claimed
locator.

Ok, then saying "I'm doing this because x.x.x.x asked me to" is superfluous.

About 5: a good start would be to make a split between the state for
incoming and outgoing sessions.


But isn't that hard for UDP, when the kernel stack doesn't explicitly
know who started the communication?

I'm still not convinced that the kernel wouldn't know this, but that's not the issue as the MH layer knows at least something relevant: if there is no state and we want to send data, we must create it so we are initiating.

Having to do work per session may not
be so bad if there is a way to quickly sync up with the state that's
already there for older sessions. Both hosts would then know they're
still talking to the same correspondent. If this fails (maybe
legitimate loss of state due to timeout) they can fall back to a full
session initialization.

But wouldn't such an ability to securely resume a previous session
require that some state is retained from that session i.e. the session
state isn't really removed? How would this be different than just
keeping all the session state? In either case there would be some timeout
or other garbage collection trigger to remove the state I think.

I'm not so much considering resuming sessions (which I don't think transport protocols do anyway) as creating new sessions that are similar as existing or very recently expired ones, think HTTP with one HTML page and 30 images, making for 31 sessions. This would be soft state: if it's there, try to use it, if not or if the other side says "huh?", do a regular init.

So this would be something like "we do multihoming. wanna clone mh state that already exists for the session defined by <...>?". The answer would then be either "..." (no multihoming, strange as they did it earlier), "sure thing" (state is there and can be reused) or "we do multihoming, and this is how we want to handle this session..." (state lost or not reusable for some reason).

Maybe a stupid idea, but would it be useful to have some mechanism to
discover insecure links? A simple way to do this would be blocking
(initial) multi6 packets on such links so initiating multihoming
negotiations over such unsafe links which may lead to later redirection
attacks becomes impossible.

Apart from the policy question, where different hosts might consider different
things "secure" vs. "not secure", would it be possible to make any form
of automatic detection of anything but the link attached to the host?

One way would be a hop-by-hop option that routers pick up on and modify. Another would be to simply filter a certain protocol and port in insecure networks and assume that any link that doesn't allow those packets through is less secure.