Hi Michael, Thanks for sharing your thoughts. If the IPsec "implementation" receives a fragmented plain text packet for encrypting and sending out then it is not really a pre-fragmentation. Pre-fragmentation requires the IPsec itself needs to decide whether to fragment an incoming plain text fragment before encrypting it. The question is, how to make that decision if MTU & packet size is decided by policy and SA. RFC asks us to use a policy with layer 3 selectors only for the non initial fragments. However, the decision to fragment can not be made without doing policy lookup. This is a circular dependancy. My suspicion is that RFC expects us to look the full L4 policy for the full packet and a subsequent policy lookup for each individual (non-initial) fragment though it does not explictly state so. This is not quite obvious from the description of the outbound processing in the RFC though and therefore my suspicion may be invalid.
Thanks and regards, Gandhar Gokhale Networking Components Group LSI On Thu, Aug 30, 2012 at 5:41 PM, Michael Richardson <[email protected]>wrote: > > >>>>> "Gandhar" == Gandhar Gokhale <[email protected]> writes: > Gandhar> relevant excerpt: *"Note: With the exception of IPv4 and > Gandhar> IPv6 transport mode, an SG, BITS, or BITW implementation > Gandhar> MAY fragment packets before applying IPsec. (This applies > Gandhar> only to IPv4. For IPv6 packets, only the originator is > Gandhar> allowed to fragment them.) The device SHOULD have a > > So, it's important to realize the "SG", "BITS" and "BITW" parts all put > the IPsec at a distance from the IP layer. So the fragmentation already > occurred before (and maybe some distance) from the IPsec policy layer. > > Gandhar> For deciding whether to fragment a packet we need to know > Gandhar> the packet's length and MTU (or PMTU but to k) ofthe > Gandhar> interface. IPsec tunnel alters length of the packet and > Gandhar> possibly outgoing interface as well. It means the policy > Gandhar> affects the decision of whether a packet would get > Gandhar> frameneted or not. However, RFC section 5.1 requires > > What we decided that we would not require, was for the SG/BITS/BITW to > assemble the fragmented packet before applying the policy. For *many* > (95%) site-to-site policies, we never need to look beyong layer-3 anyway, > so let's not make reassembly a requirement. > > Gandhar> implementation to perform policy lookup on the fragmented > Gandhar> packet. How can the implementation decide if the a packet > Gandhar> should be fragmented before knowing what policy (and SA) > Gandhar> will match? Moreover, the section 7.3 (reassembly for > Gandhar> policy verification) becomes redundant if implementation > > 7.3 is a MAY, and it's use is signaled. > If your system (because it's built into the stack) can do policy based > upon non-trivial port information, and will then fragment the packet > before tunnelling, it will therefore put packets in the tunnel which > the other end point will be unable to verify properly. > > Gandhar> Can someone please help me understand what I'm missing > Gandhar> here? > > Gandhar> Thanks and regards, Gandhar Gokhale Networking Components > Gandhar> Group LSI > > My guess is that you are building hardware, and you are trying to fit > all of the IPsec stack into your BITS hardware, not realizing that parts > can simply not be done unless the host stack is aware of your BITS. > > -- > ] He who is tired of Weird Al is tired of life! | > firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] [email protected] http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE > > > then sign the petition. > > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
