Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Xuxiaohu <[e-mail]>]

Hi Curtis,

Thanks a lot for your suggestions. I would incorporate them into the next version.

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Curtis Villamizar [mailto:[e-mail]]
> 发送时间: 2014年1月23日 4:43
> 收件人: Xuxiaohu
> 抄送: Eggert, Lars; [e-mail]; Joel Jaeggli; [e-mail]
> 主题: Re: 答复: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating
> MPLS in UDP) to Proposed Standard
> 
> 
> In message
> <[e-mail].
> huawei.com>
> Xuxiaohu writes:
> 
> > Hi all,
> >
> > Thanks a lot for your comments.
> >
> > I wonder whether the following text is OK to you:
> >
> >    Since the MPLS-in-UDP encapsulation causes MPLS packets to be
> >    forwarded through "UDP tunnels", the congestion control guidelines
> >    for UDP tunnels as defined in Section 3.1.3 of [RFC5405] SHOULD be
> >    followed. Specifically, MPLS can carry a number of different
> >    protocols as payloads. When an UDP tunnel is used for MPLS payload
> >    traffic that is known at configuration time to be IP-based and
> >    congestion-controlled, the UDP tunnel SHOULD NOT employ its own
> >    congestion control mechanism, because congestion losses of tunneled
> >    traffic will trigger an congestion response at the original senders
> >    of the tunneled traffic. When an UDP tunnel is used for MPLS
> >    payload traffic that is known at configuration time not to be
> >    IP-based and congestion-controlled, the UDP tunnel SHOULD employ an
> >    appropriate congestion control mechanism as described in
> >    [RFC3985]. Note that it STRONGLY RECOMMENDED to deploy such
> >    encapsulation technology only within a SP network or networks of an
> >    adjacent set of co-operating SPs, rather than over the
> >    Internet. Furthermore, packet filters should be added to block
> >    traffic with the UDP port number for MPLS over UDP to prevent MPLS
> >    over UDP packets to escape from the service provider networks due
> >    to misconfiguation or packet errors.
> >
> > Best regards,
> > Xiaohu
> 
> Xiaohu,
> 
> Looks good.
> 
> A few nits:
> 
> s/an congestion response/a congestion response/
> 
> s/Note that it STRONGLY RECOMMENDED/Note that it is STRONGLY
> RECOMMENDED/
> 
> s/to deploy such encapsulation technology  /that such encapsulation
> technology be deployed/
> 
> s/UDP packets to escape from/UDP packets from escaping/
> 
> I suggest that you also add a paragraph saying that UDP checksums SHOULD be
> used in all cases where it is feasible to do so.  Try to capture the reasoning
> behind the tsvwg recommendations that UDP checksums be used whenever it is
> possible to do so.  You can optionally add wording from past email outlining
> the known cases where adding UDP checksums are infeasible (such as
> cut-through routing).
> 
> thanks.
> 
> Curtis
> 
> 
> > > -----邮件原件-----
> > > 发件人: mpls [mailto:[e-mail]] 代表 Eggert, Lars
> > > 发送时间: 2014年1月22日 15:52
> > > 收件人: [e-mail]
> > > 抄送: Joel Jaeggli; [e-mail]
> > > 主题: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt>
> > > (Encapsulating MPLS in UDP) to Proposed Standard
> > >
> > > This is not at all the argument I am making. My emails have not
> > > touched at all on the issue of zero checksums.
> > >
> > > My point is that UDP encapsulation changes the potential *reach* of
> > > congestion-uncontrolled traffic that was otherwise limited to L2 networks.
> > >
> > > Lars
> > >
> > > On 2014-1-21, at 21:14, Curtis Villamizar <[e-mail]> wrote:
> > >
> > > >
> > > > In message <[e-mail]>
> > > > "Eggert, Lars" writes:
> > > >
> > > >> Hi,
> > > >>
> > > >> On 2014-1-21, at 12:50, Stewart Bryant <[e-mail]> wrote:
> > > >>> In terms of congestion and misdelivery it is interesting looking
> > > >>> at the number of horses that are already bounding around in the
> > > >>> paddock outside the stable:
> > > >>>
> > > >>> IP types: 47 (GRE) and 137 (MPLS-in-IP) for example.
> > > >>
> > > >> there is a big difference between encapsulation in IP and
> > > >> encapsulation in UDP. Everything encapsulated with "obscure" IP
> > > >> protocol numbers will get dropped by default at NATs and
> > > >> firewalls, whereas UDO traffic happily traverses them. The reach
> > > >> of UDP traffic is much broader.
> > > >>
> > > >> Lars
> > > >
> > > >
> > > > Stray UDP packets carrying MPLS getting to grandma's firewall is
> > > > really stretching the argument but ...
> > > >
> > > > When encapsulating in UDP, the UDP checksum might be zero but the
> > > > IP checksum can still be filled in so the IP destination is
> > > > checked and grandma need not worry about these packets.  But ...
> > > >
> > > > Grandma's firewall would block since there is no state established
> > > > on the firewall with the opposite port pair pattern.  But ...
> > > >
> > > > Even if it went through when the packet reached grandma's subnet
> > > > the payload is junk bound to an unused port.  Maybe it hits
> > > > grandma's DNS server and is interpreted as a badly malformed DNS
> request.
> > > >
> > > > So grandma seems safe from these bad packets.
> > > >
> > > > Lack of UDP checksum should at worst mean that the destination
> > > > gets a packet with a munged payload, pulls off the IP and UDP
> > > > headers and continues to forward.  At worst has the wrong MPLS
> > > > label and gets blackholed in the provider network somewhere.  If
> > > > it ends up at the correct MPLS egress, if IP, the IP checksum is
> > > > checked.  If a TCP or UDP payload carried in that IP got munged
> > > > the packet could end up at the destination with a bad TCP or UDP
> checksum and get dropped.
> > > >
> > > > Curtis