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.