Manish Karir wrote:
>
> On Sat, 13 Jan 2001, Fred Baker wrote:
>
> > At 01:34 AM 1/13/01 -0800, Alhussein Abouzeid wrote:
> > >ECN *is* an option. TCP may or may not use it.
> >
> > we are somehow using entirely different definitions of the word "option". I
> > am using it in the sense the word is used in RFC 791 and 793; you are using
> > it, I think, in the sense "something that is optional".
> >
> > I'm not convinced I know what bits you're going to find in the IP or TCP
> > headers that are left for doing "something that is optional", but if you
> > can, be my guest.
>
> actually there can be any number of ways of doing this as long as the
> consensus and approval of the ietf is there...
IP Options are the most awkward (and probably less suited) of these.
> for example:
>
> -the protocol field could be used to identify the packets to be spoofed.
> so we would have TCP, or TCP-SPOOF to distinguish between the two.
> (I personally think this is a good idea...if what spoofing does is
> break traditional TCP then why call it TCP..just call it something
> else...)
That's not very good for inter-working with other user stacks...
>
> -a particular combination of the flags: say for example DF combined with
> SYN combined with FIN but no ACK will mean -dont spoof
> (bad idea I know..but once again....feasible..)
>
- bad and especially so using a combination of bits across different
protocol layers.
> -or how about a certain combination of bits in the TOS field...
> (after all is'nt the purpose of the ToS field to be able to identify
> flows of different types for processing different....so we can specify
> that say ToS value of x shall mean the flow should not be spoofed or
> should be spoofed)
I believe these are already allocated to possible ECN and to DSCPs. DSCP
values are not preserved unmodified end-to-end either, so these are not
really
candidates for this use.
>
> anyways.....just some random thoughts...
TCP OPTION?
If you can find out why you want to do it, and what benefit you get, why
not consider a TCP option? I haven't heard of anyone (yet?) trying
these spoofing ideas for UDP (???). If your target is TCP, and your spoofer
**must** demultiplex individual flows and interpret TCP header semantics,
why not negotiate "willingness to spoof" on TCP connection setup? Failure
to see this option, could indicate unwillingness (including encryption? old
protocol stack? lazy application?) - I wonder whether this has more
potential?
>
> manish
It seems to me that it is not just a matter of whether
hosts mark packets with the correct identifier if they do (or do not)
know they need spoofing - but also how TCP stacks find out that their
parent application needs this facility - will the API do this (???),
I would guess applications must explicity do this by understanding
(???) how they plan to use a connection. Can this
reasonably be expected to be implemented network wide?
Another issue is whether there could be some consensus on **what**
sort of spoofing a connection tolerate. I'm skeptical, on trying
to standardise if there are a diverse set of techniques that are only used
in some types of network... ) see the PILC WG PEP document.
Best wisjhes,
Gorry
-- ------------------------------ http://www.erg.abdn.ac.uk/users/gorry
This archive was generated by hypermail 2b29 : Tue Jan 16 2001 - 12:49:10 EST