Re: threats ID

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Kurt;

> > > I think there is a notable difference. In my reading you are using 
> > > NAT very loose for all forms of address rewrite. NAT to me does 
> > > static rewrites, with no form of signaling.
> >
> > Wrong. Rewriting is not the essential problem.
> >
> > Right. The problem is lack of signaling OF *CONNECTIONS*.
> >
> > As you might know, there is no connections and signaling at
> > the IP layer.

> Right, but along the same lines of reasoning -  NAT won't break 
> anything at the _IP_ layer. It might break things at the ULPs though.

And the brokne ULPs need repairing, which means ULPs are modified.

> > Thus, the only thing NAT and other layer 3 things can do is
> > guessing the connection state by a lack of communication
> > for certain period of time, though, sometimes, you can detect
> > TCP SYN and FIN.

> I would say that this is the difference between (most) of the proposals 
> in multi6 and NAT. The proposals have provided mechanisms to let ULPs 
> handle referrals, even when there is rewriting. Something that NAT does 
> not provide.

Are you saying ULP modification necessary or not?

> > However, that you observe no traffic over a connection does
> > not necessarily mean that the connection is broken.

> True. Which is also the topic of a long thread here some time ago.

It is an obvious evidence that NAT is a bad idea, which does
not worth a long thread.

> > There is no signaling unless layer 4 and above are involved,
> > though guessing may work for TCP.
>
>
> The mechanisms to allow address rewrite will have to
>
> a) Leave to the ULPs to handle connection state and connection 
> verification. An aid in doing this might be to create a middle layer 
> (the 3.5) which functions as a recording mechanism on state.

As there can be no such thing under UDP. such a middle layer, if any,
becomes layer 4 protocol specific and is a part of the layer 4
protocol. So, call it modified layer 4.

> b) Provide a means to the ULPs to handle referrals transparently. 
> Again, this can be done with a shim layer, or in other ways.

Are you saying you modify ULPs or not?

> To dive into semantics, part of the problem/difference between multi6 
> proposals and NAT is the fact that NAT _is_ transparent to the ULPs and 
> that no state is recorded at the end-nodes.

You misunderstand NAT.

NAT (including so called IP layer multi6 proposals) is no
transparent.

NAT does not have correct knowledge on information recorded at
the ULPs of the end that NAT can not properly interoperate with
them.

							Masataka Ohta