draft remarks

[Iljitsch van Beijnum <iljitsch@muada.com>]

After reading the following drafts in preparation for monday's meeting 
I noticed some stuff.

draft-lear-multi6-things-to-think-about-03

- are there any questions about how site policy can be applied? (where 
"policy" has a big overlap with "traffic engineering"
- I would like to see a new question: "Is it possible to implement the 
solution in middleboxes?"
3.4 I think the question about MPLS traffic engineering warrants a 
pointer to what exactly this is about, as this is a layer 2 thing which 
we can't assume everyone is familiar with
2.4.12 I think it's important to split between interaction of updated 
hosts in a multihomed site with unmodified correspondents, and 
operation of "legacy" hosts in multihomed sites.
2.4.13 "compatable"?
2.4.15 An IETF meeting isn't really an example of an ad-hoc network. 
Some people sitting together and creating a network on the fly without 
being able to request address space and such would be a better example.
2.4.19 Referrals don't work all that well in IPv4 either. I think a 
"must" is too strong here. For instance, if referrals fail after a 
rehoming event I would consider that acceptable. A separate effort to 
make referrals work well regardless of multi6 would be good, too.
2.4.20 Quotation marks gone astray.
4. You misspelled my name, and Patrik's too, I think.

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.
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.
2 - address "unique identifier" can be read as "only identifier" but 
means "that uniquely identifies".
2 - identifier If not associated with an interface, then with what? 
(Host, of course... But what is a "host"?)
3.4 Slow down packets? Example please...
Page 17: "signally"?

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?

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.

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.

About 5: a good start would be to make a split between the state for 
incoming and outgoing sessions. 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.

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.

draft-huston-multi6-architectures-00

(Hm, was there a new version? I used the links from Brian's last 
announcement.)

Page 8: "teh"
Page 9: "sitines"
4.4 In theory there is a split between having site exit routers 
(actually many of the functions attributed to site exit routers here 
would be more naturally placed in middleboxes) determine which 
addresses are appropriate and then rewrite them, or have the hosts do 
this themselves. In reality, requiring all hosts AND all routers to be 
upgraded is a non-starter, so hosts must always be prepared to do this 
themselves, even if routers can do it too.
4.4 Comparing to NAT is not very appropriate as the addresses are 
written back before reaching the transport and/or application.
4.6 Note about tunneling: this is insecure as the implied relationship 
between inner and outer addresses can't be trusted. So this must be 
checked, but then the receiver knows what to expect so the actual inner 
values can be compressed away. I think we called this "aliasing" in the 
meeting.
4.6 Separate communications channel: "beware of the firewall"
5.1 ICMP triggers