Yes, I agree that this is interesting and it would allow us to treat
the flow label as an opaque binary string in all cases.

  Brian

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 
>    >   Another option for products that want to look at layer 4 information is
>    >   to define a new destination option.  One can put whatever they want in
>    >   those.
>    >=> this idea is not so silly if this destination option is at the new
>    >position, ie. between the routing header and the fragment header.
>    >This will solve the fragment classification issue (to keep some state
>    >works only if fragments are in the suitable order, at least one common OS
>    >sends to last fragment first). Of course an encapsulation device can
>    >repeat it in the outer header (like tunnel encapsulation limit option).
> 
>         the option was explored a bit in ipsec working group (NAT-friendly
>         ipsec proposal).  not sure about the current status, or security
>         implication/threat model (for example, if I were an attacker, I'd
>         try to sniff/decrypt traffic with a port # for banking transaction!).
> 
> => a security gateway can or copy the header or hide it. It can apply
> its policy with the whole information (ie. it has the header then it knows
> what information it will reveal). I think it is the best compromise
> between security and classification... Of course I assume the security
> gateway is clever (if it is dumb you can remove the security :-).
> 
> Regards
> 
> [EMAIL PROTECTED]
> 
> PS: in fact the security issue is the same than with flow label hacking,
> but an option is cleaner then should be better from any point of view...
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to