Re: draft remarks [multi6-threats]

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

That aspect is already explicitly mentioned in section 1.1.
In any case, I'll put in some "discussion" text in 1.1 as well.

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

SeND is good; doesn't mean it will be univerally deployed though.
Hopefully there will be some deployment for public access IEEE networks
at the edge, but I'm far from convinced enterprise networks will see
the benefits.

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

I guess I don't see the conflict.
The layer under discussion is "IP".

But there are only about 6 occurences of ULP in the draft and I think
all of them are actually "transport layer" so I can easily get rid
of the ULP term. Should I do that?

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

OK. So one could allow new locators to be added as long as it is possible
to check back with the original locator. That might be a useful technique.

Was there something you wanted to see changed or added in section 3.4 in the 
draft about this, or was this a comment on the solution space?

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

I'm list. Can you send a suggested edit to the text in the document?

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

Yes, we would be initiating the MH context setup.
But if the state can be garbage collected, we might not have been initiating
the application communication.

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

That seems challenging deployment-wise, because by default all existing
links would let everything through i.e. claim to be secure. I'm not sure
that is what you want.

  Erik