Re: Traffic selectors, fragments, ICMP messages and security policy problems

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Tero" == Tero Kivinen <kivinen@iki.fi> writes:
    >> The requirements:
    >> 1) port-selectors
    >> 2) support fragments
    >> 3) do gateway or BITW
    >> 
    >> are conflicting. Pick two.

    Tero> Actually no. Change the 3rd requirement to:

    Tero> 3) do multipath gateway or BITW solution, where fragments of a
    Tero> packet can go out from different SGW.

  I'm assuming that assembling fragments at either end for checking is
too expensive for high speed boxes that won't wish to queue.
  That's what we were told on the list.

    Tero> You can do gateways and BITWs without problems, but you cannot
    Tero> do that if you want to support cases where you have multiple
    Tero> SGWs and fragments of the packet can be split between those SGWs.

  Right, I agree. But aren't the gateways/BITWs going to assemble the
fragments in this case?

    Tero> How often have you seen that scenario?

  I have yet to see it. All redundant situations I've seen have a warm
spare, ready to take over. No load balancing.

    Tero> So to rephrase that statement:

    Tero> If IPSEC policy decision (AH, ESP, bypass, drop) is applied to
    Tero> fragments where policy has tunnel mode port selectors, then all
    Tero> fragments must have exactly the same processing that would be applied
    Tero> to the same packet when fully assembled. 

  I agree.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr@xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQFeK3YqHRg3pndX9AQFMrQQAhVY4gN5KbOth0rcdrzoCuAiucR6zIY6N
EL+Gi1G9Nz2tu/JLpdmV6VaKM2r5jtgcC32JnLiXs4i3fBaqFbSRq9bPygSaKLBu
4R8ZY7mZC2yocDM0fnHAgeIFvagnYVlMzAAi+wr/mHNhow+0+VWi8zBlMjF+XsWH
2ECIjyjygB8=
=qjPJ
-----END PGP SIGNATURE-----