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

Re: tunnle mode SAs...



Thanks Sami,


Sami Vaarala wrote:
> 
> Yuri and others,
> 
> > Dan Harkins wrote:
> > >
> [snip]
> > >
> > > Section 3.3.4 of RFC2402 and section 3.3.5 of RFC2406 both say that
> > > fragmentation is performed _after_ outbound IPsec processing.
> > >
> > >   Dan.
> >
> > Thanks Dan. I agree that it makes sense to define one rule only for
> packet
> > processing. And I thought such rule should be defined somewhere,
> > but I didn't know where exactly. I was also considering a situation when
> a
> > developer has difficulties of implementing IPSec above the level where
> packet
> > fragmentation is done, due to OS architecture. So, I guess he doesn't
> > have a choice but to give up. That's why I included case 1 to give him
> > a hope :-) And apparently there is no hope unless we want to break
> > this rule. I guess there is a similar rule defining case 2 for inbound
> > traffic as well.
> >
> > -Yuri
> 
> How is the following paragraph of RFC 2401 Appendix B to be understood?
> As far as I understand, it is stating that encrypting fragments in tunnel
> mode is acceptable?
> 
> What do you do with extremely large packets if you cannot fragment prior
> to encryption?  Eg. you have a 65535 byte IP packet, and you want to ESP
> tunnel it.  The processed packet is larger than maximum IPv4 packet size.
> If you are allowed to fragment this datagram eg into two roughly 32k pieces
> and tunnel them separately, there is no connectivity problem.
> 
> And as Yuri pointed out, this is no problem if your processing first
> decrypts and reassembles, and then checks policy.
> 
> -----
> 
> B.2 Fragmentation
> 
>    If required, IP fragmentation occurs after IPsec processing within an
>    IPsec implementation.  Thus, transport mode AH or ESP is applied only
>    to whole IP datagrams (not to IP fragments).  An IP packet to which
>    AH or ESP has been applied may itself be fragmented by routers en
>    route, and such fragments MUST be reassembled prior to IPsec
>    processing at a receiver.  In tunnel mode, AH or ESP is applied to an
>    IP packet, the payload of which may be a fragmented IP packet.  For
>    example, a security gateway, "bump-in-the-stack" (BITS), or "bump-
>    in-the-wire" (BITW) IPsec implementation may apply tunnel mode AH to
>    such fragments.  Note that BITS or BITW implementations are examples
>    of where a host IPsec implementation might receive fragments to which
>    tunnel mode is to be applied.  However, if transport mode is to be
>    applied, then these implementations MUST reassemble the fragments
>    prior to applying IPsec.
> 
> -----
> 
> -Sami

I would allow encrypting/decrypting fragments especially when we
have it written already. Though, then SG would have to add more
logic into packet processing. And if we do it, we are not going to
change the current behavior, but only to add functionality into SG.
I don't see a problem here and to me case 1 is not very different from
case 2 except that to cover case 1 we have to add more rules.

-Yuri