IP header options - TCP-IP

This is a discussion on IP header options - TCP-IP ; Hello, I want to define a security token in the the IP header option to get Layer 3 authentication. But do this option will be dropped by "internet" routers ? Or is there a "official" option defined in RFC, not ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: IP header options

  1. IP header options

    Hello,

    I want to define a security token in the the IP header option to get
    Layer 3 authentication. But do this option will be dropped by
    "internet" routers ?
    Or is there a "official" option defined in RFC, not "router dropable"
    to store authentication informations in IP header ?

    Thanks four your answers,

    Guillaume

  2. Re: IP header options

    On Apr 25, 9:14*am, guillaume.br...@gmail.com wrote:
    > Hello,
    >
    > I want to define a security token in the the IP header option to get
    > Layer 3 authentication. But do this option will be dropped by
    > "internet" routers ?
    > Or is there a "official" option defined in RFC, not "router dropable"
    > to store authentication informations in IP header ?



    Unfortunately, many firewalls drop options generally, or drop packets
    with any option they don't recognize (and approve of).

  3. Re: IP header options

    In article
    <9863118f-6b97-4bd2-bd3e-61ba51b00108@27g2000hsf.googlegroups.com>,
    guillaume.braux@gmail.com wrote:

    > Hello,
    >
    > I want to define a security token in the the IP header option to get
    > Layer 3 authentication. But do this option will be dropped by
    > "internet" routers ?
    > Or is there a "official" option defined in RFC, not "router dropable"
    > to store authentication informations in IP header ?


    RFC 1812 says that routers must ignore options they don't recognize. I
    interpret this as meaning that they should just pass them through, since
    they don't require any special processing by the router.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  4. Re: IP header options

    > RFC 1812 says that routers must ignore options they don't recognize. *I
    > interpret this as meaning that they should just pass them through, since
    > they don't require any special processing by the router.


    An interesting whitepaper about the way IP Options are handled in core
    and edge internet routers :
    http://www.eecs.berkeley.edu/Pubs/Te...CS-2005-24.pdf

    Nobody seems to agree on this points ....

    Thanks for all your answers,
    Guillaume

  5. Re: IP header options

    "Barry Margolin" wrote in message
    news:barmar-419257.22502325042008@newsgroups.comcast.net...
    > In article
    > <9863118f-6b97-4bd2-bd3e-61ba51b00108@27g2000hsf.googlegroups.com>,
    > guillaume.braux@gmail.com wrote:
    >
    > > Hello,
    > >
    > > I want to define a security token in the the IP header option to get
    > > Layer 3 authentication. But do this option will be dropped by
    > > "internet" routers ?
    > > Or is there a "official" option defined in RFC, not "router dropable"
    > > to store authentication informations in IP header ?

    >
    > RFC 1812 says that routers must ignore options they don't recognize. I
    > interpret this as meaning that they should just pass them through, since
    > they don't require any special processing by the router.


    the problem is there can be performance issues for forwarding options -
    Cisco boxes generally will "punt" the packet to CPU processing.

    So for a worst case example, you might go from wirespeed handling to
    software processing - that can be 1000:1 performance ratio....

    So - you should expect someone to rate limit them at best, and possibly
    throw them away entirely if they are worried about someone using this as a
    denial of service attack

    see slide 23:
    http://www.ripe.net/meetings/menog/p...astructure.pdf
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE don't copy me on replies, I'll read them in the group ***

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  6. Re: IP header options

    > Unfortunately, many firewalls drop options generally, or drop packets
    > with any option they don't recognize (and approve of).


    RFC1822 abstracts :

    In datagrams received by the router itself, the IP layer MUST
    interpret IP options that it understands and preserve the rest
    unchanged for use by higher layer protocols.
    [...]
    A router MUST ignore IP options which it does not recognize. A
    corollary of this requirement is that a router MUST implement the End
    of Option List option and the No Operation option, since neither
    contains an explicit length.

    So routers dropping packets with IP Options for any reasons (cpu load,
    QOS ...) are not RFC791 and RFC1822 compliants ...
    The Berkeley study on this points shows that 15% of the internet edge
    routers (maintained mostly by local ISP) drops options packets.

    So today, the internet IP network is NOT build on full RFC compliant
    nodes, mostly for "commercial" reasons (by ignoring some RFC
    specifications to gain performances ...).
    Internet IP core network is becoming more and more "firewalled" on its
    low layers ...

    Quite problematic for people who want to take advantage of some low
    layers specifications (like IP Header Options ... 40 byte to store and
    transport, according to the RFC, anything we want !)

    Regards,

    Guillaume BRAUX

  7. Re: IP header options

    PS : For people interested in this subject, I have also found an
    interesting thread about "non RFC1822 compliancy" (mostly about IP
    Options) :
    http://osdir.com/ml/network.end2end/.../msg00129.html

  8. Re: IP header options

    In article
    <7d86ad86-7b35-4601-9bf0-4370c2cc9031@s50g2000hsb.googlegroups.com>,
    guillaume.braux@gmail.com wrote:

    > So routers dropping packets with IP Options for any reasons (cpu load,
    > QOS ...) are not RFC791 and RFC1822 compliants ...


    Neither are routers that drop packets because of ACLs, or because of
    reverse-path filtering, etc. Pragmatics and security trump pedantic
    interoperability.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: IP header options

    On 2008-04-26 23:01:36 -0400, Barry Margolin said:

    > Neither are routers that drop packets because of ACLs, or because of
    > reverse-path filtering, etc. Pragmatics and security trump pedantic
    > interoperability.



    Great point, Barry.

    I kind of find myself on Guillaume's side in this in being sort of
    alarmed a bit about non-compliance. I think there's some set of
    "reasonable" and "non-reasonable" bending of the RFC's in this, where
    ACL's are cool, makes sense, but other options, not so much. With ISP's
    here in the US on either side of the pay-for-better-bandwidth /
    neutrality argument and our fear-mongering government trying to seize
    any control they can get, I don't consider it too far a stretch to
    think that some maligned luminary will discern a way to quietly muck
    with a rarely-used / disused option header as a way to silently filter,
    mark, or tag traffic.

    While I'm not trying to speak for the great man when I say this, I'd
    guess Jon Postel would agree, too.

    !~chrismac

    --
    _ __ _
    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


  10. Re: IP header options

    wrote in message
    news:7d86ad86-7b35-4601-9bf0-4370c2cc9031@s50g2000hsb.googlegroups.com...
    > > Unfortunately, many firewalls drop options generally, or drop packets
    > > with any option they don't recognize (and approve of).

    >
    > RFC1822 abstracts :
    >
    > In datagrams received by the router itself, the IP layer MUST
    > interpret IP options that it understands and preserve the rest
    > unchanged for use by higher layer protocols.
    > [...]
    > A router MUST ignore IP options which it does not recognize. A
    > corollary of this requirement is that a router MUST implement the End
    > of Option List option and the No Operation option, since neither
    > contains an explicit length.


    yes - and the cases i quoted work that way. The issue is not compliance, but
    scale of traffic and processing cost.

    >
    > So routers dropping packets with IP Options for any reasons (cpu load,
    > QOS ...) are not RFC791 and RFC1822 compliants ...


    no - since the RFC does not require options are processed at the expense of
    everything else.

    anyhow 1822 is an informational RFC so is not mandatory anyway - maybe you
    meant 1812?
    http://www.ietf.org/rfc/rfc1822.txt?number=1822

    http://www.ietf.org/rfc/rfc1812.txt?number=1812

    > The Berkeley study on this points shows that 15% of the internet edge
    > routers (maintained mostly by local ISP) drops options packets.
    >
    > So today, the internet IP network is NOT build on full RFC compliant
    > nodes, mostly for "commercial" reasons (by ignoring some RFC
    > specifications to gain performances ...).
    > Internet IP core network is becoming more and more "firewalled" on its
    > low layers ...


    FWIW the RFCs only "recommend" a device to be capable of operating in a
    certain way.

    Nothing then stops someone from explicitly configuring the box differently.

    and there are some thing more important than RFCs - and RFCs are explicitly
    not designed to be rigid standards implemented using tunnel vision.

    http://en.wikipedia.org/wiki/Postel's_law

    ironically the Postel law text is more or less identical to 1.3.2 in RFC
    1812.....
    >
    > Quite problematic for people who want to take advantage of some low
    > layers specifications (like IP Header Options ... 40 byte to store and
    > transport, according to the RFC, anything we want !)


    true - but IP options have been used to attack routers and hosts, and
    interoperability issues have caused problems - some of this "deliberate mis
    compliance" to coin a phrase is from that experience.

    >
    > Regards,
    >
    > Guillaume BRAUX

    --
    Regards

    stephen_hope@xyzworld.com - replace xyz with ntl



  11. Re: IP header options

    Guillaume Braux wrote:

    > I want to define a security token in the the IP header option to get
    > Layer 3 authentication. But do this option will be dropped by
    > "internet" routers ?
    > Or is there a "official" option defined in RFC, not "router dropable"
    > to store authentication informations in IP header ?


    Two relevant threads from last year.

    http://groups.google.com/group/comp....635a00350c15de
    http://groups.google.com/group/comp....e12872ff4d97fb

    Some routers slow to a crawl when routing packets carrying IP options.

    Regards.

+ Reply to Thread