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

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mpls
Subject:    Re: [mpls] AD review of draft-ietf-mpls-in-udp
From:       "Carlos Pignataro (cpignata)" <cpignata () cisco ! com>
Date:       2013-10-31 17:53:06
Message-ID: 95067C434CE250468B77282634C96ED33365369E () xmb-aln-x02 ! cisco ! com
[Download RAW message or body]

Hi,

On Oct 16, 2013, at 12:14 PM, Adrian Farrel <adrian@olddog.co.uk> 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
> 

["signature.asc" (signature.asc)]

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlJymQUACgkQtfDPGTp3USxSywCfU8Cdb4zM2xY2qpq5JdjmiqmT
q/4AoJP/U6MdcD6KLxGa50EZkGieshhX
=hkuA
-----END PGP SIGNATURE-----

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--===============8619540179231643661==--

[prev in list] [next in list] [prev in thread] [next in thread] 