[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
possible additional issues for Elliot's draft (was RE: F1000 requirements?)
Hi,
after all this F1000 requirements thread, i guess that several issues could
be considered in Elliot?s draft:
I guess that a first issue is related to renumbering efforts when rehoming,
sort of:
Rehoming costs:
Explain the impact of a rehoming event of the multihomed site. That is,
suppose that a multihomed site has deployed the solution proposed, then,
explain the modifications required when the multihomed site changes one of
its ISPs. Explain if it is required to modify all the nodes of the
multihomed site or the modifications are limited to a limited set of
devices. Explain how the rehoming event affects applications, DNS,
route-maps, filters, etc.
Additionally, at least tangentially, some Traffic Engineering requirements
were mentioned by Iljitsch, (and i think that Pekka S. also mentioned some
stuff related a while ago), in the lines of:
Traffic Engineering
Describe the Traffic Engineering capabilities of the proposed solution. In
particular does the proposed solutions allows the site to select the ISP
used to carry the traffic? Does it allow to select (or at least influence)
the ISP used for incoming traffic? For outgoing traffic? for traffic of
internally initiated communications? for traffic of externally initiated
communications? Describe how are those TE capabilities managed. In
particular, which devices have to be configured to implement a TE policy in
the multihomed sites (site exit routers, all the routers, all the hosts?)
Describe how does the defined policies are enforced. That is, which element
actually performs the path selection in each case (the intra site routing
system, the internal hosts, the external hosts)
Finally, i guess that there is the currently discussed issue about hiding
intra site location information to external hosts, something in the lines
of:
How much information about the node within the multihomed site is revealed
when communicating with an external host? Is the external host aware of the
locator of the node within the multihomed site? Is the external host aware
of the identifier of the node within the multihomed site? Describe the
lifetime of the binding between the identifier used by an external host and
the node within the multihomed site. Describe the lifetime of the binding
between the locator used by an external host and the node within the
multihomed site.
However, about this last point, i think that additional analysis is
required, since i guess that it is still not clear (for me at least) why do
you need to conceal the location/identity of the hosts within the multihomed
site, and whether you could provide the same benefits using alternative
mechanisms. I mean, why is that a risk that an external host can discover
the locator of a host, and wouldn't it be possible to provide protection
from these threats using an alternative mechanism, such as firewalls.
> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Brian E Carpenter
> Enviado el: martes, 04 de mayo de 2004 11:24
> Para: Fleischman, Eric
> CC: multi6@ops.ietf.org
> Asunto: Re: F1000 requirements?
>
>
> Eric,
>
> I don't think we can answer your question with respect to multi6
> yet. And in fact it's quite complicated, because it depends on
> whether your concern is about internal clients of external servers,
> external clients of internal servers, or multiparty sessions (aka P2P).
>
> And I don't think that discussion really belongs here. If you think
> there are specific enterprise multihoming needs that are not covered
> in RFC 3582 or draft-lear-multi6-things-to-think-about-02.txt, now
> (before the interim meeting) would be a really good time to send
> suggested text for that draft.
>
> Brian
>
> Fleischman, Eric wrote:
> > Noel,
> >
> > You have stated our intention well. The intention is indeed to
> provide an address to authorized outsiders that does not reveal
> internal network information.
> >
> > Currently (with IPv4) the "translation overhead" you allude to
> is a NAT. Can Multi6 provide for an alternative mechanism or will
> NATs remain for IPv6?
> >
> > --Eric
> >
> > -----Original Message-----
> > From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
> > Sent: Monday, May 03, 2004 1:26 PM
> > To: multi6@ops.ietf.org
> > Cc: jnc@mercury.lcs.mit.edu
> > Subject: RE: F1000 requirements?
> >
> >
> > > From: "Fleischman, Eric" <eric.fleischman@boeing.com>
> >
> > > The desire (requirement) is to have international addressability /
> > > routing without revealing the existence of internal nodes
> or network
> > > topology except to a select (controlled) group of outsiders
> >
> > Let me understand this more fully. Are there a set of entities
> outside with
> > whom which you wish to communicate, but whom you *do not* want to have
> > knowledge of your network topology?
> >
> > If so, that would imply that the information that those parties
> would have to
> > have about the local host at your site they were talking to
> would have to
> > come in two parts: i) a location as to where your whole site is
> (relative to
> > the topology of the network as a whole), and ii) an opaque
> token of some sort
> > which would have to be translated to give the location of the local host
> > within your network.
> >
> > If there are no such entities, I'm not sure what the problem
> is: you don't
> > give anyone outside the address (which would reveal your
> network topology) of
> > the local host unless they are in the set which is authorized
> to know about
> > your network - but in that case there's no problem. From which
> I conclude
> > that probably there are such entities.
> >
> > If so, are you willing to pay the translation overhead (which I
> don't see how
> > to avoid - you don't want to give them detailed information about the
> > location of the local host, ergo that information [which you
> have to have, to
> > get the packets to the local host] has to be added after it leaves the
> > source) on each packet?
> >
> > Noel
> >
> >
>