[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tunnle mode SAs...
Dan Harkins wrote:
>
> On Wed, 25 Apr 2001 16:28:16 EDT you wrote
> > Dan Harkins wrote:
> > > Isn't fragmentation done after IPsec processing? In that case #1 (for
> > > outbound) would never happen. If the other side is an endhost it
> wouldn't
> > > fragment a packet and then apply IPsec to the fragments. If it's a
> router
> > > then it'd have to reconstruct the whole packet prior to IPsec
> processing
> > > anyway, right? If the selector did not specify port and/or protocol
> > > information and the router received a fragment it would just process it
> > > like it was a normal IP datagram and you'd receive a bunch of
> > > IPsec-protected
> > > fragments.
> >
> > As I wrote above, fragmentation theoretically can be done before
> encryption.
> > I said theoretically because I don't know who is actually doing it.
> > Maybe nobody has thought about it? Why do you say it's impossible to
> > fragment before encryption? If we define the rule "fragment only after
> > encryption", I agree case 1 would never happen. I just don't see
> > why technically case 1 is impossible even considering all RFC and
> > drafts we have now. Or maybe I missed something?
>
> 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
Follow-Ups: