[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]



Iljitsch van Beijnum wrote:
> 
> On donderdag, mei 8, 2003, at 14:13 Europe/Amsterdam, Brian E Carpenter
> wrote:
> 
> > As I've said before, the actual requirement is that the lower 64 bits
> > be mutually unique among the set of correspondents (two for normal
> > cases,
> > N for p2p cases).
> 
> Is it useful to define the requirement this narrow? For a server, I
> would think it's hard to work with non-globally unique correspondents
> as potentially every host connected to the network can open a session
> at any time, creating a collision where there wasn't one previously.

I think it's a footnote on the word "global". You can say global, but 
add a note that mathematically that is not a necessary condition, although
it may be the most practical solution.

> 
> > But indeed it is a general point that non-topological
> > fields are more readily spoofed than topological fields, since
> > ingress filtering and RPF checks don't apply.
> 
> Don't forget return routability. Ingress filtering and RPF checks
> aren't done everywhere, but return routability protection is relatively
> good except when the attacker shares a subnet.

Sure

> 
> > The consequence is not automatically that they can't be used, but that
> > if they are used, an additional layer (such as HIP) is needed.
> 
> So we agree that breaking return routability and not repairing the
> resulting gap with something else isn't an option?

I think so.

> 
> Wouldn't such an additional layer always carry even more state with it?
> The only advantage is that this kind of state is kept in the endpoints.
> However, then we end up with the requirement that endpoints must
> implement the solution, which leads to deployment problems and
> management difficulties in some networks.

Right, except that we have to solve key management anyway, to make any
kind of security scale. Which as we know is hardly trivial.

> 
> This leaves us with:
> 
> 1. do it with unmodified hosts in a proxy multihoming agent and eat the
> state
> 2. do it in modified hosts and don't involve the routers
> 3. 1. on on end an 2. on the other
> 
> I don't feel the GSE way of doing it in modified hosts and then expect
> routers to do some additional work provides benefits over one of the
> above options.
> 
> > I think that is what you should say.
> 
> I'm getting there... It's still more than a month before the draft
> cutoff for Vienna.  :-)

Lots of time to solve a problem that was discovered around 1992 :-)

   Brian