Re: [mpls] mpls-in-udp entropy

In message <75996b50f08c46b5b3809ee628dadcba@AM3PR03MB532.eurprd03.prod.outlook.com>
Alexander Vainshtein writes:
> 
> Curtis,
>  
> IMHO and FWIW it is preferable to allocate the entropy port from the
> Dynamic/Private space.  14K values should suffice for any reasonable
> ECMP scenarios.
>  
> My 2c,
>      Sasha

The return address should be the sender and maybe it would be a good
idea to use port numbers that are not otherwise in use by the sender
in case something gets the packet and tries to reply, but even that is
extremely unlikely.  For the source port to get abused the host at the
other end would have to be running the wrong service on that port and
trying to reply.  Avoiding the WKP space might be a good idea only to
avoid a error reply to an error reply loop if both ends think they
have a WKP.  Even if no loop is formed a misconfigured other end could
bombard your UDP socket space.  Mistyping the dest address of the MPLS
over UDP tunnel could be quite harmfull but more likely to the other
end that has to drop a lot of misdirected packets.

Absent severe misconfiguration where the destination has another
service on that port, even using the WKP space in the source port
would be OK.

(BTW- A UDP packet with two WKPs was the basis for an old forged
packet denial of service attack before some of the very old low number
UDP echo and daytime type services were shut off by default.  For this
reason it used to be useful to run sockstat -p udp -l and make sure
you understand what is running on which port and which UDP sockets
could potentially send a "badly formed packet" reply and create a
loop.  These days you are unlikely to find this situation.).

Curtis

> ________________________________________
> From: Curtis Villamizar <curtis@ipv6.occnc.com>
> Sent: Wednesday, January 15, 2014 10:56 PM
> To: Alexander Vainshtein
> Cc: erosen@cisco.com; mpls@ietf.org
> Subject: Re: [mpls] mpls-in-udp entropy
>  
> In message <5b0765246d204750a50e1aad52a3b72e@AM3PR03MB532.eurprd03.prod.outlook.com>
> Alexander Vainshtein writes:
>  
> > Eric,
> > Lots of thanks for a prompt and highly informative response.
> >
> > I have been actually thinking about the same thing, namely that the
> > entropy port should be the result of some hash over the label
> > stack.
> >
> > If this is indeed the intention of the authors, it would make sense
> > (at least, from my point of view) of saying so in the draft. There
> > is no need to make such a statement normative, but it would really
> > help the readers (both implementors and operators) to understand
> > what it is about.
> >
> > Regards,
> >      Sasha
>  
> Avoiding the lower 8K of the port number space might not be a bad idea
> to avoid a return port being a WKP including the non-root WKP space
> used by X-Windows and other things.
>  
> Curtis
>  
>  
> > ________________________________________
> > From: Eric Rosen <erosen@cisco.com>
> > Sent: Wednesday, January 15, 2014 6:35 PM
> > To: Alexander Vainshtein
> > Cc: mpls@ietf.org
> > Subject: Re: mpls-in-udp entropy
> >
> > (Changed subject line and trimmed cc-list.)
> >
> > Sasha> I would like to understand whether this protocol can really result in
> > Sasha> reasonable distribution of traffic. "Reasonable" means that (a) there
> > Sasha> is sufficient entropy and (b) that the order in specific micro-flows
> > Sasha> is preserved.
> >
> > I thought the intention was that the encapsulator would set the UDP source
> > port based upon the entropy of the packet being encapsulated.  This only
> > requires that the encapsulator know how to properly apply ECMP to the MPLS
> > packet that is being encapsulated.  That is, compute the hash that would be
> > used to apply ECMP to the MPLS packet, and then map from that hash to a UDP
> > source port.
> >
> > E.g., two MPLS packets with the same entropy label would get the same UDP
> > source port, two MPLS packets with no entropy label but containing the same
> > TCP flow would get the same source port, etc.
> >
> > Do you think there is a problem here?
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls