Experts, out of the well-known values for ip options: X@r4# set ip-options ? Possible completions: <range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them. Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
Luca: Check http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/s ec_acl_sel_drop_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1 043334 Not the whole story, but :) Hope it helps, Dario
-----Original Message----- From: Luca Tosolini [mailto:bit.gossip@chello.nl] Sent: Wednesday, October 28, 2009 3:06 PM To: nanog Subject: ip options
Experts, out of the well-known values for ip options:
X@r4# set ip-options ? Possible completions: <range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp
I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp
But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them.
Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
On Oct 29, 2009, at 2:05 AM, Luca Tosolini wrote:
Considering the security hazard that they imply, I am therefore thinking to drop them.
You should certainly consider the impact on traceroute and possibly QoS (i.e., RSVP, if it's relevant) in your environment. Some vendors/platforms also have the option to ignore, rather than drop. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625
There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ). There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. Thanks, John
JD wrote:
There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things.
Call your vendor and demand better radius backend support for dhcp. :) The largest fallback to PPPoE is the CPE needing to terminate the PPPoE or the customer's router/computer/etc needing to do so. This can be a pain especially in business environments. I have one section of my network (maintained by counterpart, not me) that is 90% PPPoE/A. The other 10% is bridge due to customer needs and CPE limitations. I personally run all my stuff as bridge, including all the CPEs.
BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers.
I have been extremely happy with unnumbered vlans in the cisco work for terminating mass vlans from dslams that support 802.1ad. The fact that it works right next to RBE works great for me. The current IPv6 layouts aren't as pretty for this setup, though. Jack
On Cisco hardware PPPoE was cleaner if you have other ISPs' customers on your network and you want to put them in their own VRF's. I've been out of that world for a while now, so maybe it's changed. -saxon 2009/10/28 JD <jdupuy-list@socket.net>
There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ).
There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things.
Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in.
BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers.
Thanks,
John
Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in.
I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote: Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. I can't speak to which would be better on copper specifically, but in general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords. With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :) David Smith MVN.net -- Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
On Wed, 28 Oct 2009 15:33:58 -0700 Walter Keen <walter.keen@rainierconnect.net> wrote:
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote:
Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in.
DOCSIS cable networks use DHCP and have for a long time. If you have Ethernet based DSLAMs, they can usually do the a number of tricks (e.g. Option 82 insertion into the DHCP request) that would make a DHCP ADSL deployment no harder (or easier) than a DOCSIS cable network. It seems to me that the fundamental purpose of PPPoE is to be able to uniquely identify the customer for billing/provisioning purposes. Even though you only need to be able to do that at the start of their session, with PPPoE you pay an 8 byte per packet overhead, on _every_ packet sent and received by the customer. Other methods of distinguishing the customer, e.g. Option 82, static DHCP mapped to a customer MAC address, or possibly 802.1x if it were available, have much, much lower overhead. I think PPPoE really only exists to make ADSL look like high speed dial-up, so that ISPs dial up backend systems didn't need to be changed when ADSL was introduced. That was a valid concern in the past, but with existing solutions or models such as the DOCSIS Cable methods, and Ethernet based DSLAMS, I'd suggest avoiding PPPoE if you can.
I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords.
With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :)
David Smith MVN.net
--
Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
Apologies if this message is brief, it is sent from my cellphone. On 29/10/2009, at 11:33, Walter Keen <walter.keen@rainierconnect.net> wrote:
Most aDSL modems if set to PPPoE (I think Actiontec's come this way by default) will send the mac as the pppoe un/pw. David E. Smith wrote:
Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in.
I can't speak to which would be better on copper specifically, but in
general I'd favor DHCP over PPPoE. Either way, most of the back-end stuff will be similar (you'll need a way to authenticate users, turn them off and on, et cetera); the differences won't be all that big. Either you're storing their MACs in a database, or their port assignments and VLAN tags, or their usernames and passwords.
With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :)
David Smith MVN.net
--
Walter Keen Network Technician Rainier Connect (o) 360-832-4024 (c) 253-302-0194
!DSPAM:22,4ae8c6fe233691194411224!
On Wed, 28 Oct 2009, David E. Smith wrote:
With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :)
One of the reasons for UUNET's PPPOE design was to reduce phone calls and configuration hassles. But in a different way. In the "old" days, people thought there would be separation between the ISP and the wholesale network. The idea that the provider could control/manage the CPE, like a cable set-top box, was probably more radical at the time than a dumb modem and PPPOE client on the PC. PPPOE can allow changing ISPs just by changing the username@domain, without needing to call wholesale provider's tech support and reconfiguring the circuit. You could even have multiple PC's sharing the same circuit, each connecting to different ISPs at the same time. Or use PPPOE to "call" a business' DSLAM pool for work access, and then call AOL's DSLAM pool for personal use. The concept of multiple "dialers" was well supported on most operating systems, and more familar to the public at the time than trying to set hostnames or read MAC addresses in DHCP configurations. In those days, VPN/IPSEC tunnel support wasn't very common. Businesses still had dial-up modem pools, X.25 PADs, and private PPP/PPPOE/PPPOA/PPPOx connections. Compared to the overhead for other point-to-point and tunneling protocols at the time, PPPOE's overhead didn't look that bad. And since it was based on PPP, PPPOE made route addressing (and other routing stuff) easy. Addressing a single host is the simple case of the more general router PPP information. As Milo used to say, with enough thrust you could get DHCP to do many of those same things too. There were a lot of experiments, and not all of them worked well. As they say, the world changed. Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP (with lots of options) won too. We can have a betamax/vhs-style argument of technical superiority; but the market made a choice.
This current draft DHCP Authentication http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt Adds the username/password that PPP has to DHCP and I believe support IPv6. Vince -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Thursday, October 29, 2009 5:07 AM To: nanog@nanog.org Subject: Re: PPPoE vs. Bridged ADSL On Wed, 28 Oct 2009, David E. Smith wrote:
With PPPoE, however, the end-user can't just plug in and go - they'll have to configure their PC, or a DSL modem, or something. That means a phone call to your tech support, most likely. In many cases, DHCP can lead to plug-and-play simplicity, which means they don't have to call you, and you don't have to answer their calls. Everyone wins. :)
One of the reasons for UUNET's PPPOE design was to reduce phone calls and configuration hassles. But in a different way. In the "old" days, people thought there would be separation between the ISP and the wholesale network. The idea that the provider could control/manage the CPE, like a cable set-top box, was probably more radical at the time than a dumb modem and PPPOE client on the PC. PPPOE can allow changing ISPs just by changing the username@domain, without needing to call wholesale provider's tech support and reconfiguring the circuit. You could even have multiple PC's sharing the same circuit, each connecting to different ISPs at the same time. Or use PPPOE to "call" a business' DSLAM pool for work access, and then call AOL's DSLAM pool for personal use. The concept of multiple "dialers" was well supported on most operating systems, and more familar to the public at the time than trying to set hostnames or read MAC addresses in DHCP configurations. In those days, VPN/IPSEC tunnel support wasn't very common. Businesses still had dial-up modem pools, X.25 PADs, and private PPP/PPPOE/PPPOA/PPPOx connections. Compared to the overhead for other point-to-point and tunneling protocols at the time, PPPOE's overhead didn't look that bad. And since it was based on PPP, PPPOE made route addressing (and other routing stuff) easy. Addressing a single host is the simple case of the more general router PPP information. As Milo used to say, with enough thrust you could get DHCP to do many of those same things too. There were a lot of experiments, and not all of them worked well. As they say, the world changed. Ethernet won, vertically integrated ISPs won, VPN won, and yes DHCP (with lots of options) won too. We can have a betamax/vhs-style argument of technical superiority; but the market made a choice.
Vince Mammoliti wrote:
This current draft
DHCP Authentication
http://www.ietf.org/id/draft-pruss-dhcp-auth-dsl-06.txt
Adds the username/password that PPP has to DHCP and I believe support IPv6.
Now if we could just tweak things perfectly so customers can hook up, log in to the ISP, and use tickets to access everything and it's dog, that would rock. :) A nice extension to allow corporate networks to interface with that system would be even cooler. *dreams of a secure authenticate once world* Jack
On Thu, Oct 29, 2009 at 11:10 AM, Jack Bates <jbates@brightok.net> wrote:
*dreams of a secure authenticate once world*
It may be worth noting here that there are times were one wants barriers between automation to keep malfunction or malice from spreading too far without human involvement. Of course, most of the current barriers we have are accidental, random, and ill-defined, so there's clearly room for improvement either way. :) -- Ben
On Thu, 29 Oct 2009, Vince Mammoliti wrote:
This current draft
DHCP Authentication
That's what makes protocol wars so much fun. With enough options, almost any protocol can do almost anything. As you know, I did my best to kill PPPOx at an ISP and in the IPTV architecture several vendors were selling at the time. I still think that sometimes DHCP is the answer, and other times PPPOx is the answer, but you can usually make either work if necessary. And even though I chose DHCP, the vendor needed to fix several things. I haven't kept track if all of them were really fixed.
We like PPPoE on the edge because we can use RADIUS to apply policy to the subscribers for bandwidth management, class-of-service, SNPs, etc. You probably have some of these features via your DSLAM, but we found it easier to do via RADIUS with a web based GUI for our provisioning folks. So if we need to snip someone's Internet and leave voice or VPN packets alone due to an abuse issue for example, we can apply the policy that references the appropriate ACL. George
On Wed, 28 Oct 2009, JD wrote: I think the important thing is to have a separate L2 isolation per customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX will both solve this problem, but deploying multicast TV offering might be harder in this deployment model. There is really no devices out there to securely do IPv6 to the end user natively when you have a shared L2 domain (in v4 this implies the L2 device will do DHCP snooping and do filtering based on that). I don't really like tunneling, so I'd advocate the q-in-q model with separate vlan per customer (or having the L3 routing very close to the customer so you don't need to do q-in-q but still can do separate vlan per customer). -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote:
I think the important thing is to have a separate L2 isolation per customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX will both solve this problem, but deploying multicast TV offering might be harder in this deployment model.
In general, it shouldn't be. Local multicast TV offerings should be transmitted out of band from the standard internet connection, either different vlan or outside of the PPPoE. The nature of it usually indicates a specialized CPE maintained by the provider to support the necessary QOS, and division of Internet and Video traffic. For public multicast, splitting in the local pop just doesn't matter much.
There is really no devices out there to securely do IPv6 to the end user natively when you have a shared L2 domain (in v4 this implies the L2 device will do DHCP snooping and do filtering based on that).
Several vendors claim to have v6 support for this in the next year. Currently, many of them completely break v6 due to the v4 security. Jack
For telco-delivered IPTV, the multicast channel, bi-directional control channel, and video are transmitted on different VP/VC. For VDSL2, I'm guessing it would be a different VLAN. Frank -----Original Message----- From: Jack Bates [mailto:jbates@brightok.net] Sent: Thursday, October 29, 2009 10:03 AM To: nanog@nanog.org Subject: Re: PPPoE vs. Bridged ADSL Mikael Abrahamsson wrote:
I think the important thing is to have a separate L2 isolation per customer so you can more easily deploy IPv6 in the future. q-in-q or PPPoX will both solve this problem, but deploying multicast TV offering might be harder in this deployment model.
In general, it shouldn't be. Local multicast TV offerings should be transmitted out of band from the standard internet connection, either different vlan or outside of the PPPoE. The nature of it usually indicates a specialized CPE maintained by the provider to support the necessary QOS, and division of Internet and Video traffic. For public multicast, splitting in the local pop just doesn't matter much.
There is really no devices out there to securely do IPv6 to the end user natively when you have a shared L2 domain (in v4 this implies the L2 device will do DHCP snooping and do filtering based on that).
Several vendors claim to have v6 support for this in the next year. Currently, many of them completely break v6 due to the v4 security. Jack
Others commented on things I already had in mind only the username/password thing of PPPoE. We use the same username/pw on the modem as the customer users for their e-mail, so a password change necessitates a truck roll (I know, I know, TR-069). We started with PPPoE for our FTTH, because we were familiar with it, but we moved over to a "VLAN per service" model which ends up something like RBE in function. We can track customers based on the Option 82 info, so we're good to go in terms of tracking them. Frank -----Original Message----- From: JD [mailto:jdupuy-list@socket.net] Sent: Wednesday, October 28, 2009 4:21 PM To: NANOG list Subject: PPPoE vs. Bridged ADSL There is a debate among our engineering staff as to the best means of provisioning broadband service over copper facilities. Due to our history, we have a mix out in the field. Some customers are on DSLAMS set up for bridged connections with DHCP; isolated by a variety of means including VLANS. Some customers are on PPPoE over ATM. Some customers are on PPPoE over ethernet (PPPoEoE ?? :) ). There seem to be pros and cons to both directions. Certainly true bridging has less overhead. But modern CPEs can minimize the impact of PPPoE. PPPoE allows for more flexible provisioning; including via RADIUS. Useful for the call center turning customers on/off without NOC help. But VLAN tricks can sometimes do many of the same things. Opinions on this? I'd be interested in hearing the latest real world experience for both and the direction most folks are going in. BTW, I doubt it is relevant to the discussion, but most of our DSLAMS are Adtran TA5000s (or are being migrated to that platform.) We are mostly a cisco shop for the upstream routers. Thanks, John
On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote:
Others commented on things I already had in mind only the username/password thing of PPPoE. We use the same username/pw on the modem as the customer users for their e-mail, so a password change necessitates a truck roll (I know, I know, TR-069). We started with PPPoE for our FTTH, because we were familiar with it, but we moved over to a "VLAN per service" model which ends up something like RBE in function. We can track customers based on the Option 82 info, so we're good to go in terms of tracking them.
You can have a "network username/password" for the customer different from the mail and other application-layer username/password. Some ISPs did that in the dial-up days, and also with PPPOx. The network account information is configured in the dialer or router/modem; and most users never need to know the network-layer stuff. The user can change their mail/application password (and use it for off-network access) without affecting their network-layer pasword. The same network account may have multiple mail/application accounts associated with it. It also helps in the debate whether you store unreversable passwords or cleartext passwords for things like CHAP/PAP; need to split accounts because people change households; network re-architecture moves circuits around or users move and re-associating the connections with the correct accounts. Yep, I sometimes found two households with swapped VPI/VCI, VLAN or PORT identifiers because someone/something made a data entry or circuit termination mistake. I like a combination of 802.1x and Option 82 as way of cross-checking, and layer 2/3 anti-spoof protection. I also like handling network things mostly at the network/hardware level, separate from the application layer identity so the user changes aren't affected. But there are almost always multiple ways to solve a problem.
Hindsight being what it is, we would have likely had a separate account/password for the PPP account. I guess we could theoretically have two layers of RADIUS checking, the first layer being the application-layer username/password, and failing that, the original username/password that we assigned to the PPP device. Frank -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Saturday, October 31, 2009 3:14 PM To: NANOG list Subject: RE: PPPoE vs. Bridged ADSL On Thu, 29 Oct 2009, Frank Bulk - iName.com wrote:
Others commented on things I already had in mind only the username/password thing of PPPoE. We use the same username/pw on the modem as the customer users for their e-mail, so a password change necessitates a truck roll (I know, I know, TR-069). We started with PPPoE for our FTTH, because we were familiar with it, but we moved over to a "VLAN per service" model which ends up something like RBE in function. We can track customers based on the Option 82 info, so we're good to go in terms of tracking them.
You can have a "network username/password" for the customer different from the mail and other application-layer username/password. Some ISPs did that in the dial-up days, and also with PPPOx. The network account information is configured in the dialer or router/modem; and most users never need to know the network-layer stuff. The user can change their mail/application password (and use it for off-network access) without affecting their network-layer pasword. The same network account may have multiple mail/application accounts associated with it. It also helps in the debate whether you store unreversable passwords or cleartext passwords for things like CHAP/PAP; need to split accounts because people change households; network re-architecture moves circuits around or users move and re-associating the connections with the correct accounts. Yep, I sometimes found two households with swapped VPI/VCI, VLAN or PORT identifiers because someone/something made a data entry or circuit termination mistake. I like a combination of 802.1x and Option 82 as way of cross-checking, and layer 2/3 anti-spoof protection. I also like handling network things mostly at the network/hardware level, separate from the application layer identity so the user changes aren't affected. But there are almost always multiple ways to solve a problem.
Folks, I would love to see the IETF OPSEC WG publish a document on the pros and cons of filtering optioned packets. Would anybody on this list be willing to author an Internet Draft? Ron (co-director IETF O&M Area) Luca Tosolini wrote:
Experts, out of the well-known values for ip options:
X@r4# set ip-options ? Possible completions: <range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp
I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp
But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them.
Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
How about unused and/or private/local diffserve code points? Ron Bonica wrote:
Folks,
I would love to see the IETF OPSEC WG publish a document on the pros and cons of filtering optioned packets.
Would anybody on this list be willing to author an Internet Draft?
Ron (co-director IETF O&M Area)
Luca Tosolini wrote:
Experts, out of the well-known values for ip options:
X@r4# set ip-options ? Possible completions: <range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp
I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp
But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them.
Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
:-) ----- Original Message ---- From: joel jaeggli <joelja@bogus.com> To: Ron Bonica <rbonica@juniper.net> Cc: nanog <nanog@nanog.org> Sent: Wed, November 4, 2009 3:41:26 AM Subject: Re: ip options How about unused and/or private/local diffserve code points? Ron Bonica wrote:
Folks,
I would love to see the IETF OPSEC WG publish a document on the pros and cons of filtering optioned packets.
Would anybody on this list be willing to author an Internet Draft?
Ron (co-director IETF O&M Area)
Luca Tosolini wrote:
Experts, out of the well-known values for ip options:
X@r4# set ip-options ? Possible completions: <range> Range of values [ Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-id Stream ID strict-source-route Strict source route timestamp Timestamp
I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp
But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them.
Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
participants (19)
-
Ben Scott -
Dario Ciccarone (dciccaro) -
David E. Smith -
Frank Bulk - iName.com -
George Carey -
isabel dias -
Jack Bates -
JD -
joel jaeggli -
Luca Tosolini -
Mark Smith -
Mikael Abrahamsson -
Nathan Ward -
Roland Dobbins -
Ron Bonica -
Saxon Jones -
Sean Donelan -
Vince Mammoliti -
Walter Keen