Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?

From: "David Smith (djsmith)" <[email-masked]>
Date: Sun, 2 Nov 2008 03:49:05 -0500

Hi Renwei,

See feedback below [dasmith].

Renwei> I understand that the crafted IP options may be exploited by
malicious users to launch attacks, but some software vendors also
develop their software tools based on the options. The Class 2 options
can't be simply ignored.

[dasmith] We're not suggesting the LER ignore them. We're proposing the
LER MPLS encapsulate them (by default) when its matching prefix-based
FEC specifies a MPLS LSP tunnel. The MPLS network would then be seen as
no more than 2 hops (ingress LER + egress LER). The intent is only to
define the ingress LER behavior as default and mandatory to implement,
not to prohibit LER flexibility. We can refine the text to make clearer
if adopted by the WG.

Renwei> If an LER makes an IP packet un-routable because LSR doesn't
install BGP routes, the particular LER has an implementation problem. 

[dasmith] Well, the packet may be perfectly routable by the LER (which
carries BGP routes) but not routable by downstream LSRs (which do not
carry BGP routes). So such traffic gets dropped in the MPLS core yet
both the LER and the LSRs fully conform to existing MPLS WG standards.
Or worse, traffic flows fine but now the MPLS core is susceptible to a
variety of security issues. Should we not define a simple default LER
forwarding rule to resolve this? Again, we are not opposed to LER
flexibility and are willing to make the text clearer but all LERs should
support this default forwarding rule.
 
Renwei> As I said before, if an IP packet has options inside, there has
to be some reasons for the options. Sometimes, if LER doesn't look at
the options, the packet can't be correctly forwarded. For example, if
the packet wants to be selectively broadcast to multiple destinations,
the options must be examined. Moreover, IP options are also used for
research and experiment. In such cases, such experimental options are
sometimes expected to be processed at each hop.

[dasmith] The LERs can fully process the IP options per above. But note,
forcing the LSR to process the options may break transit applications
(research, enterprise or otherwise) if the LSR doesn't carry the BGP
routes per above. Many MPLS network operators do not want their LSRs
processing transit IP option packets due to security reasons. Tunneling
such packets via an MPLS LSP between LERs mitigates the security risks
while not breaking the transit applications that legitimately use IP
option pkts. 

Renwei> As suggested before, it could be a CLI knob to turn on/off the
feature.

[dasmith] Ok, but we still need to specify that LERs must support the
ability to MPLS encapsulate packets with IP header options. Otherwise,
transit applications may break if LSRs do not carry BGP routes or the
MPLS network may be susceptible to IP options-based security attacks. 

Renwei> If you try to standardize the forwarding path in LER, you have
to consider all the possible IP options. 

[dasmith] The LERs can process IP options normally. We simply propose
LERs support MPLS encapsulation for IP option packets similar to all
other transit IP packets. If a network operator requires a different
behavior based on their use of IP options, that flexibility can be
provided by the LER, however, LERs should support the ability to MPLS
encapsulate IP option packets and this should be the default LER
forwarding rule. 

Regards,

/dave

-----Original Message-----
From: Renwei Li [mailto:[email-masked]] 
Sent: Monday, October 27, 2008 6:46 PM
To: David Smith (djsmith); 'Loa Andersson'; [email-masked]
Cc: 'Ross Callon'; 'David Ward'
Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?

Hi Dave,

I understand that the crafted IP options may be exploited by malicious
users to launch attacks, but some software vendors also develop their
software tools based on the options. The Class 2 options can't be simply
ignored.

If an LER makes an IP packet un-routable because LSR doesn't install BGP
routes, the particular LER has an implementation problem. 

As I said before, if an IP packet has options inside, there has to be
some reasons for the options. Sometimes, if LER doesn't look at the
options, the packet can't be correctly forwarded. For example, if the
packet wants to be selectively broadcast to multiple destinations, the
options must be examined.

Moreover, IP options are also used for research and experiment. In such
cases, such experimental options are sometimes expected to be processed
at each hop.

As suggested before, it could be a CLI knob to turn on/off the feature.

If you try to standardize the forwarding path in LER, you have to
consider all the possible IP options. 

Regards,

Renwei

> -----Original Message-----
> From: David Smith (djsmith) [mailto:[email-masked]]
> Sent: Friday, October 24, 2008 8:50 AM
> To: [email-masked]; Loa Andersson; [email-masked]
> Cc: Ross Callon; David Ward
> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
> 
> 
> Hi Renwei,
> 
> Rather than a local LER implementation issue, I'd say this is really a

> LER "forwarding issue". And the MPLS WG has defined many standards on 
> "forwarding issues". Consider RFC3443 (TTL Processing in MPLS 
> Networks) and RFC3270 (MPLS Support of DiffServ). Our draft 
> complements RFC3443 and RFC3270.
> 
> >Moreover, when an IP packet has an option, it usually has a reason 
> >for having such an option, and thus expects to be processed along the

> >forwarding path in the network.
> 
> Keep in mind one reason (used by an attacker) may simply be "DoS
LSRs".
> While the attacker hopes the packet is processed along the forwarding 
> path, the MPLS network operator expects it to be tunnelled via an LSP.
> 
> >In this case, an ingress LER is essentially just one hop away from 
> >the exit LER. The processing of such options on LER should be no 
> >different from on other routers
> 
> This is not true for IP option packets. For packets w/o IP options 
> this is true because they are LSP tunnelled from ingress LER to egress
LER.
> However, for packets "with" IP options this MAY not be true (depending

> upon the ingress LER implementation) because such option packets are 
> IP routed downstream and NOT LSP tunneled.
> 
> I'll argue this is a LER & LSR inter-op issue because the LSRs may not

> be carrying BGP routes and, if so, cannot route (unlabelled) transit 
> packets that were not MPLS encapsulated by the ingress LER.
> 
> For these reasons, I think the MPLS WG needs a well-defined (ingress) 
> LER forwarding rule to mitigate the risk of IP option packets on MPLS 
> networks (ie, LSRs).
> 
> Regards,
> 
> /dave
> 
> 
> -----Original Message-----
> From: Renwei Li [mailto:[email-masked]]
> Sent: Thursday, October 23, 2008 10:10 PM
> To: David Smith (djsmith); 'Loa Andersson'; [email-masked]
> Cc: 'Ross Callon'; 'David Ward'
> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
> 
> Hi Dave,
> 
> I do see your point. But it is really a local implementation issue. 
> With or without it, LER would still work. It could at most serve as a 
> CLI knob which can be turned on or off according to whatever someone 
> wants, but it doesn't look like a requirement for LER.
> 
> > If so, should we not promote a consistent implementation among 
> > vendor LERs via
> 
> It depends on what you mean by "consistent implementation"? If it has 
> an effect on inter-op for LERs from different vendors, no doubt we 
> should promote it and I will fully support it. But if it doesn't have 
> anything to do with inter-op, I am afraid we should not promote it. 
> There are so many different LERs that have different local 
> implementations inside, but they are just fine provided they inter-op.
> 
> Moreover, when an IP packet has an option, it usually has a reason for

> having such an option, and thus expects to be processed along the 
> forwarding path in the network. In this case, an ingress LER is 
> essentially just one hop away from the exit LER. The processing of 
> such options on LER should be no different from on other routers.
> 
> Regards,
> 
> Renwei
> 
> 
> > -----Original Message-----
> > From: David Smith (djsmith) [mailto:[email-masked]]
> > Sent: Thursday, October 23, 2008 7:17 AM
> > To: [email-masked]; Loa Andersson; [email-masked]
> > Cc: Ross Callon; David Ward
> > Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG
doc?
> >
> >
> > Hi Renwei,
> >
> > Yes, it's a local LER decision.....but the LER implementation has 
> > consequences on downstream LSRs.
> >
> > Do you agree that failing to MPLS encapsulate a IPv4 packet simply 
> > because it has an IP option header may be a problem for the 
> > downstream
> 
> > network?
> >
> > If so, should we not promote a consistent implementation among 
> > vendor LERs via an MPLS WG standard such that when an LER decides 
> > "whether to
> 
> > push an MPLS label stack onto an IP packet, the determination is 
> > made without considering any IP options that may be carried in the 
> > IP packet header"??
> >
> > Regards,
> >
> > /dave
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf

> > Of Renwei Li
> > Sent: Thursday, October 23, 2008 1:38 AM
> > To: 'Loa Andersson'; [email-masked]
> > Cc: 'Ross Callon'; 'David Ward'
> > Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG
doc?
> >
> > Opposed.
> >
> > This draft imposes a new requirement on LER. But the new requirement

> > has nothing to do with inter-op. Moreover, the new requirement is 
> > really a matter of local implementation, and doesn't look really 
> > like
> a "MUST"
> > requirement.
> >
> > Regards,
> >
> > Renwei
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On 
> > > Behalf
> 
> > > Of Loa Andersson
> > > Sent: Tuesday, October 21, 2008 1:14 PM
> > > To: [email-masked]
> > > Cc: Ross Callon; David Ward
> > > Subject: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
> > >
> > > Working Group,
> > >
> > > we have been asked to adopt draft-dasmith-mpls-ip-options-01.txt
> > > as a WG doc.
> > >
> > > This is to start a two week poll. Please send your comments on 
> > > whether
> >
> > > you think this is ready to become a wg document.
> > >
> > > George and Loa
> > >
> > > --
> > > Loa Andersson
> > >
> > > Principal Networking Architect
> > > Acreo AB                           phone:  +46 8 632 77 14
> > > Isafjordsgatan 22                  mobile: +46 739 81 21 64
> > > Kista, Sweden                      email:  [email-masked]
> > >                                            [email-masked] 
> > > _______________________________________________
> > > mpls mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> > _______________________________________________
> > mpls mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: kris foster <[email-masked]>
Date: Mon, 3 Nov 2008 01:49:57 -0800

I have read the draft and support its adoption as a WG item.

Kris

---

From: Nathan Patrick <[email-masked]>
Date: Mon, 03 Nov 2008 09:46:07 -0800

I support this draft wholeheartedly. Removing attack vectors is key to
the stability of the Internet, and this one is rather insidious.

I vote yes.

-Nathan