Subject: Re: draft remarks

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 00:45:17 -0700 (PDT)

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jun 2004 18:15:48 +0200

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

>> monitor and inject but not block.

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

> above IP" and add some words about applications would that correct 

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.

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

> Are you commenting on the first paragraph of 4.3?

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

> that you actually need to verify that the peer is present at the 

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

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

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

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 2004 05:26:45 -0700 (PDT)

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

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

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

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

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

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

> there is no state and we want to send data, we must create it so we are 

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.

> 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