Subject: draft remarks

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Jun 2004 10:12:35 -0700

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Jun 2004 16:12:55 +0200

Hi!

I've reworked the document based on Geoff's comments.  Questions are the 
same, but just in different order.

> "policy" has a big overlap with "traffic engineering"

You mean like access-lists?  There are specific questions regarding TE.

4.2  Does your solution impact existing traffic engineering methods,
     such as MPLS-TE?

    Traffic engineering allows for source-based traffic aggregation to a
    particular destination.  How will your mechanism interact with such
    existing methods?

> solution in middleboxes?

3.10  Middlbox interactions

    What are the implications for firewalls?  What are the interactions
    with NAT?  What are the interactions with web caches? What
    complications are introduced with your solution?  For instance, are
    there implication for ingress filters?  If so, what are they?

"
> we can't assume everyone is familiar with

Got a suggestion?

> hosts in a multihomed site with unmodified correspondents, and operation 
> of "legacy" hosts in multihomed sites.

This is where 2.4.15 was going.  Is that not sufficient?

    How will your solution interact with
> being able to request address space and such would be a better example.

You mean like our just concluded interim meeting? ;-)  You're right. 
And that's a case to point out.  What I really meant were short-lived 
network associations.  We could probably use iPass or T-Mobile as the 
case in point I actually had in my head.

> make referrals work well regardless of multi6 would be good, too.

This is an area that I think needs just a bit more work, in any event. 
First of all, this is not a requirements document, and if you read it as 
such, then I went afoul of my own intent.  But beyond that, many people 
*are* concerned about what the binding between location and address 
means.  For instance, will that binding vary based on who's asking? 
Will the same binding work if one of the two correspondents move?  FTP 
was (I thought) the trivial case of this, because time is not generally 
a factor.  Of course, firewalls are.

> 2.4.20 Quotation marks gone astray.

doh.

> 4. You misspelled my name, and Patrik's too, I think.

doh * 2.  My apologies to you both.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 18 Jun 2004 22:55:45 +0200

On 18-jun-04, at 16:12, Eliot Lear wrote:

>> - are there any questions about how site policy can be applied? 
>> (where "policy" has a big overlap with "traffic engineering"

> You mean like access-lists?  There are specific questions regarding TE.

No, ACLs or traffic engineering in general are not not what I mean. 
Different people mean different things when they talk about policy. The 
subset that I'm interested in is the situation where a network is 
multihomed, and it wants/needs to reach certain destinations over one 
particular link under normal circumstances. In a situation where 
decisions by hosts determine the link used for incoming and/or outgoing 
packets, there is no obvious way to push such a policy out to all hosts 
within the site.

>> - I would like to see a new question: "Is it possible to implement 
>> the solution in middleboxes?

>    there implication for ingress filters?  If so, what are they?

This question assumes that the solution is implemented somewhere (such 
as in hosts) and asks how otherwise unrelated middleboxes are going to 
function in the presence of multihoming. What I'm getting at is that 
the situation that the solution is implemented inside a middlebox or 
site exit router such that unodified hosts can benefit from being 
multihomed. That's a different issue.

>> pointer to what exactly this is about, as this is a layer 2 thing 
>> which we can't assume everyone is familiar with

> Got a suggestion?

No. Quite the reverse: I'd like to read such a document in order to see 
what all the fuss is about.

> This is where 2.4.15 was going.  Is that not sufficient?

At first glance this seems to be about deployment scenarios, this 
question isn't very clear.

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

> You mean like our just concluded interim meeting? ;-)

Right. I was also thinking about networks without any connectivity at 
all, but I just realized those aren't going to be multihomed so they 
are of no interest to us.  :-)

> We could probably use iPass or T-Mobile as the case in point I 
> actually had in my head.

I've never heard of iPass and T-Mobile is the outfit that bills me for 
using my cellphone, so I'm not sure if those names are helpful...

> First of all, this is not a requirements document, and if you read it 
> as such, then I went afoul of my own intent.

Yes, this alone is sufficient reason to remove the "must". However, I 
was overlooking that fact and arguing that even in a requirements 
document (which this isn't and we don't have) this requirement would 
probably be too strong.

> But beyond that, many people *are* concerned about what the binding 
> between location and address means.  For instance, will that binding 
> vary based on who's asking? Will the same binding work if one of the 
> two correspondents move?  FTP was (I thought) the trivial case of 
> this, because time is not generally a factor.  Of course, firewalls 
> are.

FTP is an interesting case because it supports a controller X directing 
Y to send a file to Z and Z to receive it from Y. Now consider the 
situation where X communicates with addresses Y1 and Z1, but Y and Z 
can only reach each other at Y2 and Z2.

I guess all of this is solvable by introducing an identifier and a 
mapping service, or going through a reverse, forward DNS lookup cycle 
(if the FQDN - host relationsip is 1-on-1), but I think this is a 
challenging problem in its own right rather than just a footnote in the 
history of multihoming.

Iljitsch

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 21 Jun 2004 09:55:42 +0200

On 2004-06-18, at 22.55, Iljitsch van Beijnum wrote:

>>> rehoming event I would consider that acceptable. A separate effort 
>>> to make referrals work well regardless of multi6 would be good, too.
>
>> This is an area that I think needs just a bit more work, in any 
>> event. First of all, this is not a requirements document, and if you 
>> read it as such, then I went afoul of my own intent.
>

While I agree that a must would imply that the document have some form 
or requirements status, referrals are of such a strong demand from 
applications that I think this needs to be addressed one way or the 
other. But at the interim meeting we already said that we would try and 
cover applications requirements in some way. So I agree with Iljitsch 
but I do think that the question should be in the document. Perhaps we 
could also come up with some more sub-questions for this point for 
helping describing exactly how referrals would work.

- - kurtis -

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Jun 2004 10:04:48 +0200

> helping describing exactly how referrals would work.

Right.  What I was aiming for was something along these lines:

Referrals

    How will your solution handle referrals, such as those within FTP or
    various conferencing or other peer to peer systems?

    Referrals exist within various other protocols, such as so-called
    "peer to peer" applications.  Note that referrals might suffer three
    types of failure:
       firewall and NAT - just as FTP active mode experiences today with
       relatively simple firewalls?
       time-based - is there something ephemeral about the nature of the
       solution that might cause a referral (such as a URL) to fail over
       time, more so than what we have today?
       location-based - if the binding varies based on where the parties
       are in the network, if one moves will they no longer be able to
       find one another?

And the following:

What application/API changes are needed?

    Will old code just work with the new mechanism? For instance, what
    about code that uses gethostbyname()?

    Will getaddrinfo() need to change?

    What about other API calls?

    There are several possible approaches.  For instance, a multihoming
    service could attempt to require no changes to the API, in which case
    it is possible that IP addresses might become opaque blobs that work
    with the API, but might break operational assumptions at the
    application layers.  Consider the case of a web server that wants to
    log IP addresses.  How will it accomplish this task?

    One useful exercise would be to provide code fragments that
    demonstrate any API changes.

Eliot

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 21 Jun 2004 10:58:58 +0200

On 2004-06-21, at 10.04, Eliot Lear wrote:

>> While I agree that a must would imply that the document have some 
>> form or requirements status, referrals are of such a strong demand 
>> from applications that I think this needs to be addressed one way or 
>> the other. But at the interim meeting we already said that we would 
>> try and cover applications requirements in some way. So I agree with 
>> Iljitsch but I do think that the question should be in the document. 
>> Perhaps we could also come up with some more sub-questions for this 
>> point for helping describing exactly how referrals would work.
>

Ok!

- - kurtis -

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Jun 2004 10:51:52 -0700

Eliot Lear wrote:

>> other. But at the interim meeting we already said that we would try 
>> and cover applications requirements in some way. So I agree with 

Also, within a single endsystem (e.g., conventional FTP) or among 
different endsystems.

>       are in the network, if one moves will they no longer be able to

Or will two parties who aren't moving be able to use exchanged referral 
info...

Joe