Re: [mpls] AD review of draft-ietf-mpls-in-udp

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi,

On Oct 16, 2013, at 12:14 PM, Adrian Farrel <[e-mail]> wrote:

> Hello,
> 
> Just cutting down to the conversation...
> 
>>> Abstract
> [snip]
>>> "...applicable in some circumstances" says nothing, of course. Either
>>> don't say this, or explicitly state the circumstance. Since (see below)
>>> the applicability is very specific and there is a clear use case that is
>>> the target of your work, I strongly suggest that you call out this case
>>> in the Abstract.
>> 
>> Is it ok for you if the above sentence is changed to"... applicable in some
>> circumstances where IP-based encapsulation for MPLS is required and fine-
>> grained load-balancing of IP tunneled MPLS packets is required as well..."?
> Or can
>> you suggest any text on this point?
> 
> That helps a lot.
> Thanks.

I do not think adding the proposed text is the best fix. Saying "circumstances where IP-based encapsulation for MPLS is required and fine-grained load-balancing of IP tunneled MPLS packets is required as well" implies potentially that existing IP-based encapsulation for MPLS are not appropriate for fine-grained load-balancing of IP tunneled MPLS packets, and that's not necessarily the case, since fields in other encapsulations can be used (and are used) for that (e.g., GRE Key, L2TPv3 Session ID).

Also, this proposal contradicts your (Adrian's) point below about the inability to know what's encapsulated in MPLS (the proposed text says "of IP tunneled MPLS packets").

Additionally, please note that RFC 4023 says in the abstract "Each of these is applicable in some circumstances." which sets the expectation that it will be answered in the doc as applicability.

I'd propose just removing the "...applicable in some circumstances" or be even more specific about the applicability.

> 
>>> Introduction
> [snip]
>>>   This encapsulation allows for two Label Switching Routers (LSR) to
>>>   be adjacent on a Label Switched Path (LSP), while separated by an
>>>   IP network.
>>> 
>>> This makes it sound like a new feature, but (of course) MPLS-in-IP and
>>> MPLS-in-GRE allows this as well.
>> 
>> How about adding "Like other IP-based encapsulation methods (e.g., MPLS-in-
>> GRE)..." ahead of this sentence?
> 
> Perfect.
> 
>>> Section 3 Source Port of UDP
> [snip] 
>>> Furthermore, the text is not clear about the objective of "providing
>>> entropy". What type of algorithm should the source use and what must it
>>> not do?
>>> 
>>>                For example, the
>>>                entropy value can be generated by performing hash
>>>                calculation on certain fields in the customer packets
>>>                (e.g., the five tuple of UDP/TCP packets).
>>> 
>>> I find this to be a poor example because the source has in hand an MPLS
>>> packet with an arbitrary label stack and an unknown payload. Indeed,
>>> your Section 5 notes that the MPLS payload might not be TCP or UDP.
>> 
>> Our intention is whatever algorithm is actually used by the source to generate
> an
>> entropy should be irrelevant to the data encapsulation and therefore it should
> be
>> outside the scope of this doc. The entropy could be obtained from a hash of
>> certain fields, or directly obtained from the IPv6 flow label in the case of
> IPv6
>> packet, or obtained from an entropy label in the case of a MPLS packet. The
>> above just gives a simple example. How about adding explicitly " whatever
>> algorithm is actually used by the source to generate an entropy is outside the
>> scope of this doc " to the above sentence?
> 
> I think that your proposed text is good.
> I wonder whether it might be good (as well as adding your text) to remove the
> example.
> 
>>> Section 3 UDP Checksum
>>> 
>>> I note that RFC 6935 says that using a zero UDP checksum for a UDP
>>> tunnel is appropriate when the payload protocol header includes its own
>>> protection. MPLS headers do not contain this form of protection. How do
>>> you justify the zero checksum in this case?
>> 
>> It said in this doc, "The usage of this field is in accordance with the
> current UDP
>> specification. To simplify the operation on egress PE routers, this field is
>> RECOMMENDED to be set to zero in IPv4 UDP encapsulation case, and also in IPv6
>> UDP encapsulation case if appropriate [RFC6935] [RFC6936]". That's to say, in
> case
>> of IPv4 UDP tunnel, it's recommended to set to zero since the IPv4 header have
>> the similar checksum field. In case of IPv6 UDP tunnel, it's recommend to set
> to
>> zero "if appropriate". In other words, if inappropriate, this field is not set
> to zero
>> in accordance with the current UDP specification [RFC768]. Whether or not it's
>> appropriate is judged according to the specifications defined in [RFC6935]
>> [RFC6936] ,e.g.,
>> 
>>  "3.   A transported protocol that encapsulates Internet Protocol (IPv4
>>        or IPv6) packets MAY rely on the inner packet integrity checks,
>>        provided that the tunnel protocol will not significantly
>>        increase the rate of corruption of the inner IP packet.  If a
>>        significantly increased corruption rate can occur, the tunnel
>>        protocol MUST provide an additional integrity verification
>>        mechanism.  Early detection is desirable to avoid wasting
>>        unnecessary computation, transmission capacity, or storage for
>>        packets that will subsequently be discarded". (quoted from
>> http://tools.ietf.org/html/rfc6936#page-21)
>> and
>>   "5.   A transported protocol with a non-tunnel payload or one that
>>        encapsulates non-IP packets MUST have a CRC or other mechanism
>>        for checking packet integrity, unless the non-IP packet is
>>        specifically designed for transmission over a lower layer that
>>        does not provide a packet integrity guarantee". (quoted from
>> http://tools.ietf.org/html/rfc6936#page-21)"
>> 
>>> I also don't think that proper attention has been paid to Section 5 of
>>> RFC 6936. You need to examine the requirements and describe additional
>>> behavior within your document.
>> 
>> Did you mean that we should add more detailed descriptions like:
>> 
>>       "if the MPLS payload is Internet Protocol (IPv4
>>        or IPv6) packets. it MAY rely on the inner packet integrity checks...
> "
>>   and
>>        "If the MPLS payload is non-IP packets, the UDP checksum MUST NOT be
> set
>>        to zero
>>        for checking packet integrity, unless the non-IP packet is
>>        specifically designed for transmission over a lower layer that
>>        does not provide a packet integrity guarantee..."
> 
> OK, I get it.
> I suppose if was "if appropriate" that I stumbled on. 
> 
> On the other hand, you seem to believe that it is possible to know the payload
> of the MPLS flow at the time of encapsulation into UDP. I am very worried by
> this claim because:
> - you don't want to sniff every packet, nor do you want to vary whether 
>  zero checksum is used per packet
> - it is not possible to know for certain what the payload of every MPLS
>  packet on an LSP will be just by looking at a few packets
> - while LSP end points may know the payload, it is unlikely that LSP
>  mid-points will know
> - you may have multiple LSPs carried in one UDP-source-port tunnel
> 
> So it seems to me that with MPLS as the transported protocol (which is the only
> intention of this document) using a zero checksum in UDP for IPv6 would never be
> appropriate because MPLS does not include its own CRC or other mechanism, and
> because you cannot know whether the payload of MPLS is using a CRC.
> 
> If I am correct and it is never appropriate, it would be better to say that
> "using zero checksum is NOT RECOMMENDED because of..."   and then point to the
> text you quoted.
> 
> if I am incorrect then please discuss with me further.

A further point that does not imply you are incorrect, but I will note that other MPLS-in-IP encapsulations do not have a checksum in the transport, and perhaps that's what needs to be added to the document.

Thanks,

-- Carlos.

> 
>>> Section 4
>>> 
>>>   As for other common processing procedures associated with tunneling
>>>   encapsulation technologies including but not limited to Maximum
>>>   Transmission Unit (MTU) and preventing fragmentation and reassembly,
>>>   Time to Live (TTL) and differentiated services, the corresponding
>>>   "Common Procedures" defined in [RFC4023] which are applicable for
>>>   MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be followed.
>>> 
>>> I think it is probably important to consider PMTU in the presence of
>>> ECMP (probably not necessary in the case of LAG). How does the source
>>> know the PMTU for each different value of the source port that it might
>>> apply?
>> 
>> IMHO, it is a common issue for any load-balancing mechanism. Would it be
> better
>> to write a separate doc to address this common issue?
> 
> That is a really good question.
> I think discovering PMTU is technology dependent, but the general issue of
> discovery in ECMP doesn't appear to be well discussed.
> 
>>> As far as I can see Section 5 is not ECN-friendly and says that when the
>>> payload protocol of the MPLS packet is not "TCP-friendly" the
>>> application generating the packets must use magic to avoid swamping the
>>> network.
>>> 
>>> We will see what the TSV area congestion experts have to say, but I
>>> think we will find that the approach here is simplistic unless the
>>> network across which the UDP tunnel runs is used for no other traffic
>>> except UDP tunnels carrying MPLS packets.
>> 
>> We originally just intented to mention this issue to the same extent as MPLS
> over
>> L2TPv3 [rfc4817]. BTW, it seems that MPLS in IP or GRE [RFC4023] doesn't
>> mention this point at all. We would like to see what the TSV area congestion
>> experts have to say as well on this point.
> 
> Yeah, this is fine. I am not an expert in this stuff and we will need their
> opinions. Perhaps they won't say anything :-)
> 
>>> Section 6 seems to indicate a major draw-back of this scheme. You have
>>> to note that MPLS networks are able to get away with having very little
>>> security because it is very hard to inject MPLS packets into a network.
>>> But MPLS-in-(foo-in-)IP encapsulation provides a way to inject packets
>>> just like any packet can be injected into an IP network.
>> 
>> Sure. It's the same issue with any other IP-based encapsulations for MPLS.
> 
> Indeed, hence my point about security, below...
> 
>>> Security (such as IPsec) provides a way to ensure that rogue packets do
>>> not have their headers stripped and their payload MPLS packets added to
>>> an LSP.
>> 
>>> You are making a clear statement that using IPsec means that there is no
>>> point in doing MPLS-in-UDP encapsulation. You need to follow up on this!
>>> 
>>> The first thing to do is to enhance the applicability text in Section 1
>>> to say where you would deploy this such that security is not an issue.
>> 
>>> The second thing is to talk about the security mechanisms that can be
>>> applied at the edges of the network to reduce the likelihood of such
>>> attacks being possible.
>>> 
>>> Lastly (or probably firstly!) you need to describe the attack vector and
>>> the implications of such an attack so that the implementer/deployer is
>>> clear what the risks are.
>> 
>> Will fix it.
> 
> OK. I also wonder whether you looked at DTLS.
> 
> Thanks for all the work.
> 
> Adrian
>