The MPLS WG Archive

[Mark Duffy <mduffy@quarrytech.com>]

Hi Eric,  I have a few comments on the most recent draft of mpls-in-ip-or-gre.

--------------------

In sect. 5.1:

    THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY
    IN THE CASE WHERE PACKETS ARE NOT TO BE FRAGMENTED.

(md) Is that meant to mean "... WHERE *TUNNEL* (i.e. GRE or IP-in-IP) 
PACKETS ARE NOT TO BE FRAGMENTED"?  (I don't think it really matters 
whether IP packets *inside* the mpls are fragmented, see my next comment ...)


    Obviously, if packets are not to be fragmented, the tunnel head MUST
    NOT fragment a packet before encapsulating it.

(md) Since it is not possible to fragment an MPLS packet, I presume that 
refers to an LER fragmenting an IP packet before encapsulating it in MPLS 
and further encapsulating it in GRE or IP-in-IP.  But such fragmentation 
does not seem to present the sort of problem being discussed in this 
section, namely that of the tunnel tail needing to perform the 
reassembly.  In fact, this is discussed in the final paragraph of the 
section.  Perhaps the sentence quoted above ("Obviously ...") should be 
removed?


    In some cases, the tunnel head receives, for encapsulation, an IP
    packet, which it first encapsulates in MPLS and then encapsulates in
    MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
    reachable from the tunnel head, and if the result of encapsulating
    the packet in MPLS would be a packet whose size exceeds the Tunnel
    MTU, then the value which the tunnel head SHOULD use for the purposes
    of fragmentation and PMTU discovery outside the tunnel is the Tunnel
    MTU value minus the size of the MPLS encapsulation.  (That is, the
    Tunnel MTU value minus the size of the MPLS encapsulation is the MTU
    that needs to get reported in ICMP messages.)  The packet will have
    to be discarded but the tunnel head should send the IP source of the
    discarded packet the proper ICMP error message as specified in
    [RFC1191] or [RFC1981].

(md) The final 2 sentences there seem to assume that the inner packets have 
the DF bit set (or perhaps that we are dealing with an IPv6 packet) and 
will not be fragmented.  Why?  I propose dropping the last sentence and 
rewording the 2nd-to-last along the lines of:

    (That is, the
    Tunnel MTU value minus the size of the MPLS encapsulation is the MTU
    that needs to get reported in ICMP messages or used to fragment the
    received IP packet.)

---------------------

In sect. 8.1

    At the tunnel tail, IPsec outbound processing recovers the contained
    MPLS-in-IP/GRE packet. The tunnel tail then strips off the
    encapsulating IP/GRE header to recover the MPLS packet, which is then
    forwarded according to its label stack.

(md) s/IPsec outbound processing/IPsec inbound processing/
In the IPsec terminology decapsulation/decryption is part of "inbound" 
processing.


    Recall that the tunnel tail and the tunnel head are LSP adjacencies,
    which means that the topmost label of any packet sent through the
    tunnel must be one which was distributed by the tunnel tail to the
    tunnel head.  The tunnel tail MUST know precisely which labels it has
    distributed to the tunnel heads of IPsec-secured tunnels.  Labels in
    this set MUST NOT be distributed by the tunnel tail to any LSP
    adjacencies other than those which are tunnel heads of IPsec-secured
    tunnels.  If an MPLS packet is received without an IPsec
    encapsulation, and if its topmost label is in this set, then the
    packet MUST be discarded.

(md) I presume the desired objective here is to prevent acceptance of 
unencrypted packets from mpls peers that are supposed to send packets via 
an encrypted mpls-in-ip tunnel.  Is the scenario here that the peer is 
trusted, and the label distribution to the peer is secure, but packets sent 
to us by the peer must traverse an unsecured network?

I think there are serious obstacles to achieving the goal in the stated 
manner.  Unless the label distribution protocol is point-point it is 
difficult in practice to ensure that any particular labels are not 
distributed to the tunnel head of non-IPsec-protected tunnels.  Consider 
the case of 2547 VPNs with route reflectors used.  When a PE distributes a 
VPNv4 route to a route reflector, it does not control which other PEs the 
RR distributes that labelled route to.  They may be a mix of PEs that are 
adjacent over IPsec-secured tunnels, and PEs that are otherwise adjacent.

I think the objective can perhaps be met in another way:  IPsec inbound 
processing (at the tunnel tail) will apply its security policy to the 
IP-in-IP (or GRE) packets it extracts from IPsec.  This policy may be 
configured to require IPsec protection for IP-in-IP (GRE) packets from 
certain tunnel heads and not to require it from other tunnel heads.  What 
this approach does not provide is a way to reject packets that arrive in an 
MPLS (only) encaps in cases where an IPsec-secured tunnel was desired.  I'm 
not sure if that check is a requirement, or whether it is acceptable to 
protect that case by the old expedient of not accepting labelled packets 
from outside the domain?   Probably rejection of labelled packets from 
outside is needed anyway:

As described in the draft, certain labels are only accepted if they are on 
packets that arrive in secured IP tunnels, and other labels are 
(presumably) accepted no matter how they arrive.  I think this allows 
adversaries to try to make up labels in the second category and transmit 
spoofed packets with those labels.  The only way I see to secure against 
that is to a) disallow acceptance of mpls packets from outside the domain 
AND b) disallow acceptance of unsecured IP-tunneled mpls packets from 
outside the domain.  And once you do that, there is no need to distribute 
separate "must arrive with IPsec protection" and "need not arrive with 
IPsec protection" labels.

----------

Sorry about the long-windedness :-(
Thanks, Mark