[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inbound vs outbound?



On Wed, 4 Jul 2001, mahdavi wrote:

> Hi.
>
> > That is not correct.  Again, RFC2401 states "The SPD must be consulted
> > during the processing of all traffic (INBOUND and OUTBOUND), including
> > non-IPsec traffic."
>
> I did not said that I dont consult SPD. I just said
>
> "every packet is outbound else it destined to my machine in tunnel mode.
> after inbound process on such a packet I have to process it as outbound"
>
> so you can see that I consult SPD in outbound process.
>
> > Here is an attack that can happen if you don't follow this rule.  Suppose
> > that there is a packet that the attacker wants to inject into the system.
> > It might be, for example, a UDP packet that kicks off an RPC procedure on
> > the target system.  Since the attacker has access only to an section of
> > the cloud where all such packets are IPSec protected, he shouldn't be
> > able to do so.  However, with your proposed method, all the attacker
> > would have to do is inject the packet in the clear.  When this packet
> > hits the security gateway, he'll see that it didn't have the router as
> > the destination, and hence just forward it on, and hence, the attacker
> > has won.
> >
>
> Oooooh. you R wrong with my opinion.
>
> I just said
>
> "every packet is outbound else it destined to my machine in tunnel mode.
> after inbound process on such a packet I have to process it as outbound"
Or, in other words (simplifying just a little):

  "Decrypt anything that was encrypted, and encrypt anything that wasn't"

>
> you can see that any packet will go under outbound IPsec operation according
> to my opinion.
>
> so you attacker cant win me .
>
> ok ?
>
> am I right ?
No, even in cases where you have a relatively trivial topology (for
example, topologies where you don't have to worry about decrypting and
then reencrypting a packet, or with nested encryption).  Consider the
case:

          Attacker
             |
     +---+   V   +---+
 A --| B |-------| C |-- D
     +---+       +---+

where A and D are the protected hosts, and B and C are routers using your
interpretation of IPSec policy.  Then, all the attacker needs to do is
form a plaintext packet from A to D, and send it to one of B's interface.
Since it is not destined to B in tunnel mode, B will process it as
outbound.  Since packets from A to D need to be IPSec protected, B will
encapsulate it in an appropriate SA, which it will forward to C.  C will
then decrypt the packet into the original A to D packet, which it will
forward to D.  D will then get a valid looking packet that was actually
chosen by the attacker.

>
> It is better for me to redefine my sentence as follows.
>
> look at below figure.
>
>
> ----------------\
>                 |     ______________
> ------------    |    /
>            |    |    |
>         ___|____|____|____
>        /                  \
>        |                __________
>        |   ROUTER      /          \
> -------|               |          |
>        |               |  IPSEC   |
>        |               |          |
>        |               |  system  |
> -------|               |          |
>        |               |          |
>        |               |          |
>        |               \__________/
>        |                  |
>        \__________________/
>           |    |    |
>           |    |    |
> ----------/    |    |
>                |    \________
>                |
>
>
> it has many interfaces but there is no relation between interfaces and IPsec
> system.
> router work in this manner that gives every packet that is comming on any
> interface to IPsec.
> IPsec system will act on it then it generates new packet and gives it back
> to the router.
> then router will continue his work.
>
> best regards
>
> mahdavi
>
>
>
References: