Re: draft remarks

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

Sorry for the delay in responding and thank you for the comments.

> draft-nordmark-multi6-threats-02
> 
> 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. Countermeasures that address these 
> threats but not the one where an attacker can also block traffic could 
> still be useful.

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.
On-path attackers that need to monitor might be lucky and find a
non-switched Ethernet in the path, or use capacitive or inductive coupling
to listen on a copper wire.
But if the attacker is on an Ethernet that is on the path,
whether switched or not, the attacker can also employ ARP/ND spoofing
to get access to the packet flow which allows blocking as well.
Similarely, if the attacker has access to the wire, the attacker can also
place a device on the wire to block.
Other on-path attacks would be those that gain control of a router or a switch
(or gain control of one of the endpoints) and I think those would allow
blocking as well.

So the strongest case I can think of for monitoring (and injecting?)
being easier than blocking is when switches and routers have monitoring
capabilities (for network management or for lawful intercept)
where an attacker might be able to bypass the authentication and authorization
checks for those capabilities.

Are there others that you have in mind?

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

> 2 - address "unique identifier" can be read as "only identifier" but 
> means "that uniquely identifies".

Will fix.

> 2 - identifier If not associated with an interface, then with what? 
> (Host, of course... But what is a "host"?)

I'll add explicit mention of host. Something like:
identifier  - an IP layer identifier for an IP layer endpoint 
(             (stack name in [NSRG]), that is, something that might be 
              commonly referred to as a "host".

Is the "what is a host" a question you think the draft needs to address?

> 3.4 Slow down packets? Example please...

I'll add: that is, X can disable any flow or congestion control mechanism 
such as Explicit  Congestion Notification [ECN].

> Page 17: "signally"?

fixed

> BTW, it occurs to me that we can avoid some problems by imposing some 
> restrictions on the FQDN <-> (identifier) <-> IP address/locator 
> relationship(s). I.e., no longer allowing an FQDN to point to more than 
> one host. Would this be a reasonable thing to do and/or useful?

I think that's out of the scope for the threats draft.
If we are talking about a solution, I don't think it is necessary to
add such a restriction. The revision to NOID I hope to finish soon
allows FQDNs that point at multiple hosts as a result of being robust against
inconsistencies in the DNS information and the configuration of the host
itself. Thus the peers would exchange their locators in the clear
and the non-null intersection between what the peer said and what the
DNS said about the peer will be used.

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

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

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

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

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

Do you have a concrete example of how such a thing could work and be used?

  Erik