The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Mar> msg00367



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[PWE3] MPLS PID

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Thu, 27 Mar 2003 15:11:37 -0500
  • Cc: "'Thomas D. Nadeau'" <tnadeau@lucidvision.com>, "'George Swallow'" <swallow@cisco.com>, "W. Mark Townsley" <townsley@cisco.com>, "Andrew G. Malis" <Andy.Malis@vivacenetworks.com>, "'mpls@uu.net'" <mpls@UU.NET>, tnadeau@cisco.com

Title: RE: [PWE3] MPLS PID

Hi Venkata:

> -> Hang on....
> -> Using CRC as a sanity check (ensuring somthing starting
> -> with 0x04 is actually an IP packet) prior to load balancing
> -> is the suggestion, an imperfect improvement assuming the
> -> first nybble cannot be completely trusted as authoritative
> -> indication of payload type. Suggesting that it is then
> -> vulnerable to malicious attacks is a non-sequitor.
>
>   More than malicious attacks, my strong objection is
>   because of the approximations in the suggestion. If
>   all that we want to achieve is to find the payload type
>   then that should not be *guessed* by some approximations
>   or probabilistic method. Propose something concrete to
>   identify the payload type. In networking all such
>   approximation algorithms are called hacks. In the history
>   there is such a hack called henk-hack already :-)

See Eric's last post, summarizes the overall situation quite nicely although some may not agree with the proposed resolution ;-). As to the above, I agree with you which is why I explicitly said "imperfect solution".

 
> -> The goal is to avoid misordering flows across the network.
>
>   If that is the goal, why even to bother to find the payload
>   type. Search for and reserve a bit (just a bit) - for example
>   from EXP bits (if not used from Diffserv) - then ask the
>   sender to set the bit as NL (no-load-balance bit). This acts
>   just as good as Don't fragment (DF) bit in IP Header. But,
>   I suppose that won't suffice for your requirement.

It probably would if such a bit were available. T'would have been nice to have an OAM bit too....

>
> -> A rogue packet is a flow unto itself and would only
> -> impact its neighbors if load spreading was somehow stateful.
>
>   If that is the case, we shouldn't have spent so much time
>   in security. The difficult thing is to find whether the
>   packet is *real-rogue* packet or *rogue packet relative to IP*

I don't think load spreading cares....

cheers
Dave