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

From: Loa Andersson <[email-masked]>
Date: Tue, 21 Oct 2008 22:13:37 +0200

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

---

From: "Kenny Hong (kehong)" <[email-masked]>
Date: Wed, 22 Oct 2008 11:28:48 -0700

yes 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Loa Andersson
Sent: Tuesday, October 21, 2008 3: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,

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

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Wed, 22 Oct 2008 22:28:03 +0200

support.

---

From: Renwei Li <[email-masked]>
Date: Wed, 22 Oct 2008 22:38:08 -0700

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

> Sent: Tuesday, October 21, 2008 1:14 PM
> To: [email-masked]

---

From: "David Smith (djsmith)" <[email-masked]>
Date: Thu, 23 Oct 2008 10:17:23 -0400

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.

Regards,

Renwei

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Loa Andersson

---

From: Renwei Li <[email-masked]>
Date: Thu, 23 Oct 2008 19:09:59 -0700

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. 

> 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

> From: David Smith (djsmith) [mailto:[email-masked]]
> Sent: Thursday, October 23, 2008 7:17 AM
> To: [email-masked]; Loa Andersson; [email-masked]
> Subject: RE: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
> 
> 
> Hi Renwei,
>

---

From: "David Smith (djsmith)" <[email-masked]>
Date: Fri, 24 Oct 2008 11:49:41 -0400

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. 

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

> without considering any IP options that may be carried in the IP 
> packet header"??
> 
> Regards,
> 
> /dave
> 
> 
> Of Renwei Li
> 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"

> > whether

---

From: Renwei Li <[email-masked]>
Date: Mon, 27 Oct 2008 15:46:05 -0700

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

> Sent: Friday, October 24, 2008 8:50 AM

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 27 Oct 2008 23:57:04 -0000

I too am a bit concerned about this draft.

Unlike Renwei, I'm not too worried about experimental options. I don't think 
these are supposed to escape into the wider network, so we should not let 
them drive our decision-making.

However, I do agree that it worrying to make this standards track. It really 
does seem to be trying to define as mandatory an implementation behavior 
that might reasonably be flexible for different reasons.

If the use of IP options in the core is sufficiently worrying, why not 
disable them on the core routers?
If two IP packets carry different explicit paths in their options, why 
should they not be directed to different (explicitly routed) LSPs to conform 
to those routes even though they carry the same FEC?

There are plenty of questions like these and I don't feel that requiring an 
LER to conform to some behavior is beneficial.

Additionally, will you also be specifying the correct behavior of an LSR 
that receives an IP packet that carries options but that is not carried by 
an LSP when the LSR believes the packet should be carried by an LSP?

Now, if you made the I-D advice with suitable warnings, I might take a 
different view. This would be an Informational I-D not a BCP.

I would prefer more time to be spent discussing these ideas before the 
working group decides to embrace this work.

Cheers,
Adrian

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

---

From: Eric Rosen <[email-masked]>
Date: Wed, 29 Oct 2008 10:08:19 -0400

I believe this draft is meant to solve a very simple problem.

It  has been observed  that there  are MPLS  implementations which  will not
encapsulate IP packets that have options.  

In many  environments, this behavior  is undesirable.  However, it  has been
observed that there  are some implementations in which  this behavior cannot
be shut off.

The draft  attempts to  avoid this  situation in the  future by  setting two
rules:

1. It  must be possible  to configure  an LER such  that it will  apply MPLS
   encapsulation irrespective of the presence of IP options.

2. This configuration setting is the default.

However,  the draft  also specifies  that  this is  not meant  to alter  the
processing of control protocols such as RSVP which may use IP options.

So I see basically two grounds on which this draft may be opposed:

- One might think it is perfectly  okay to have an MPLS implementation which
  cannot be configured to label packets that have IP options.

  This doesn't seem reasonable to me.

- One might  think that  the labeling  of a packet  with options  should not
  necessarily be the default behavior.

  This seems more  more reasonable, at least in  theory.  However, given the
  fact that IP  options have been in disrepute for  several decades, I don't
  really see that there's any problem caused by making this the default.

Adrian> It  really  does  seem  to  be  trying to  define  as  mandatory  an
Adrian> implementation  behavior  that  might  reasonably  be  flexible  for
Adrian> different reasons. 

I  think  the  intent  is  only  to define  the  behavior  as  mandatory  to
implement, not to prohibit the flexibility.

Adrian> If the use  of IP options in the core  is sufficiently worrying, why
Adrian> not disable them on the core routers?

I think that's  usually done, but I don't  see what that has to  do with the
fact that an LER may have refused to label a packet with options.

Adrian> If two IP  packets carry different explicit paths  in their options,
Adrian> why  should they not  be directed  to different  (explicitly routed)
Adrian> LSPs to conform to those routes even though they carry the same FEC?

This behavior  is not ruled  out if some  network wants to  support explicit
routing via IP  options.  Since the percentage of  service provider networks
that support  this is, err, low,  I don't think  it can be argued  that this
should be the default behavior.

Renwei> This draft imposes a new requirement on LER. But the new requirement
Renwei> has nothing to do with inter-op.

If some  router implementation  cannot label IP  packets that  have options,
then that implementation cannot operate as an LER in certain environments.  

Renwei> It could at most  serve as a CLI knob which can  be turned on or off
Renwei> according to whatever someone wants, 

All the draft does is make the CLI knob (and its default setting) mandatory.

Renwei> Moreover, when an  IP packet has an option, it  usually has a reason
Renwei> for having  such an option, and  thus expects to  be processed along
Renwei> the forwarding path in the network

I can't say what expectations the creator of such a packet may have had, but
if he  really expected  special processing all  along the path  through some
arbitrary network, then  he's expecting a practice which  hasn't been common
since the early days of the Internet.

Renwei> Some software vendors also develop their software tools based on the
Renwei> options 

The draft is really concerned with data packets, and isn't meant to prohibit
the use of IP options on  the control/monitoring protocols which are used in
a particular network environment.