Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
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 aFrom mpls-bounces at ietf.org Mon Oct 27 16:57:19 2008
Return-Path: <mpls-bounces at ietf.org>
X-Original-To: mpls-archive at megatron.ietf.org
Delivered-To: ietfarch-mpls-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id B0AEA28C172;
Mon, 27 Oct 2008 16:57:19 -0700 (PDT)
X-Original-To: mpls at core3.amsl.com
Delivered-To: mpls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 889BA28C193
for <mpls at core3.amsl.com>; Mon, 27 Oct 2008 16:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id fF6r1Xo5D-ki for <mpls at core3.amsl.com>;
Mon, 27 Oct 2008 16:57:17 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248])
by core3.amsl.com (Postfix) with ESMTP id C086528C16C
for <mpls at ietf.org>; Mon, 27 Oct 2008 16:57:16 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1])
by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id
m9RNv9NJ031065 for <mpls at ietf.org>; Mon, 27 Oct 2008 23:57:09 GMT
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com
[81.140.15.32]) (authenticated bits=0)
by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id
m9RNv8CG031059 for <mpls at ietf.org>; Mon, 27 Oct 2008 23:57:08 GMT
Message-ID: <C48632358EF74F6595B4090FF4B42A39 at your029b8cecfe>
From: "Adrian Farrel" <adrian at olddog.co.uk>
To: <mpls at ietf.org>
References: <009801c9357d$aed57a60$0301a8c0 at china.huawei.com><42591A81B59EA14BAA617596482F65CE05E9E0AF at xmb-rtp-212.amer.cisco.com>
<001601c93885$cd87e190$63d9c10a at china.huawei.com>
Date: Mon, 27 Oct 2008 23:57:04 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [mpls] draft-dasmith-mpls-ip-options-01.txt as a WG doc?
X-BeenThere: mpls at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Adrian Farrel <adrian at olddog.co.uk>
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls>
List-Post: <mailto:mpls at ietf.org>
List-Help: <mailto:mpls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>,
<mailto:mpls-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mpls-bounces at ietf.org
Errors-To: mpls-bounces at ietf.org
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
differ
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" <renweili at huawei.com>
To: "'David Smith (djsmith)'" djsmith at cisco.com; "'Loa Andersson'"
<loa at pi.nu>; <mpls at ietf.org>
Cc: "'Ross Callon'" <rcallon at juniper.net>; "'David Ward'" <dward at cisco.com>
Sent: Monday, October 27, 2008 10:46 PM
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:djsmith at cisco.com]
Sent: Friday, October 24, 2008 8:50 AM
To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
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:renweili at huawei.com]
Sent: Thursday, October 23, 2008 10:10 PM
To: David Smith (djsmith); 'Loa Andersson'; mpls at ietf.org
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:djsmith at cisco.com]
> Sent: Thursday, October 23, 2008 7:17 AM
> To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
> 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: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf
> Of Renwei Li
> Sent: Thursday, October 23, 2008 1:38 AM
> To: 'Loa Andersson'; mpls at ietf.org
> 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: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf
> > Of Loa Andersson
> > Sent: Tuesday, October 21, 2008 1:14 PM
> > To: mpls at ietf.org
> > 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: loa.andersson at acreo.se
> > loa at pi.nu
> > _______________________________________________
> > mpls mailing list
> > mpls at ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
ent 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" <renweili at huawei.com>
To: "'David Smith (djsmith)'" djsmith at cisco.com; "'Loa Andersson'"
<loa at pi.nu>; <mpls at ietf.org>
Cc: "'Ross Callon'" <rcallon at juniper.net>; "'David Ward'" <dward at cisco.com>
Sent: Monday, October 27, 2008 10:46 PM
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:djsmith at cisco.com]
Sent: Friday, October 24, 2008 8:50 AM
To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
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:renweili at huawei.com]
Sent: Thursday, October 23, 2008 10:10 PM
To: David Smith (djsmith); 'Loa Andersson'; mpls at ietf.org
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:djsmith at cisco.com]
> Sent: Thursday, October 23, 2008 7:17 AM
> To: renweili at huawei.com; Loa Andersson; mpls at ietf.org
> 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: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf
> Of Renwei Li
> Sent: Thursday, October 23, 2008 1:38 AM
> To: 'Loa Andersson'; mpls at ietf.org
> 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: mpls-bounces at ietf.org [mailto:mpls-bounces at ietf.org] On Behalf
> > Of Loa Andersson
> > Sent: Tuesday, October 21, 2008 1:14 PM
> > To: mpls at ietf.org
> > 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: loa.andersson at acreo.se
> > loa at pi.nu
> > _______________________________________________
> > mpls mailing list
> > mpls at ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls
>
>
> _______________________________________________
> mpls mailing list
> mpls at ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
