[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PMTU/DF issues
On Tue, 22 Apr 1997, Karen Seo wrote:
> =========================================================================
> Appendix X -- Analysis/Discussion of PMTU/DF/Fragmentation Issues
>
> ****************************************************************************
> Overall, the fragmentation/reassembly approach described above works
> for all cases examined.
>
> The results for each of the 24 cases is shown below ("works" = will
> work if system fragments after outbound IPSEC processing, reassembles
> before inbound IPSEC processing). Notes indicate implementation
> issues.
>
> b. Hosts (Bump-in-the-stack) -- put IPSEC between IP layer and
> network drivers. In this case, the IPSEC module would have to
> do something like one of the following for fragmentation and
> reassembly.
> - do the fragmentation/reassembly work itself and
> send/receive the packet directly to/from the network
> layer. In AH or ESP transport mode, this is fine. In
> AH or ESP tunnel mode where the tunnel is to the
> ultimate destination, this is fine. But in AH or ESP
> tunnel modes where the tunnel end is different from
> the ultimate destination and where the source host is
> multi-homed, this approach could result in sub-optimal
> routing because the IPSEC module may be unable to
> obtain the information needed (LAN interface and
> next-hop gateway) to direct the packet to the
> appropriate network interface. This is not a problem
> if the interface and next-hop gateway are the same for
> the ultimate destination and for the tunnel end. But
> if they are different, then IPSEC would need to know
> the LAN interface and the next-hop gateway for the
> tunnel end.
Seems to me that if the interface and next-hop gateway are different for
the ultimate destination and for the tunnel end, then the tunnel end is not a
security gateway.
> ****************************************************************************
>
> 3. Path MTU Discovery -- As mentioned earlier, "ICMP PMTU" refers to an
> ICMP message used for Path MTU Discovery.
>
> A. The amount of information returned with the ICMP message is limited
> and this affects what selectors are available to identify security
> associations, originating hosts, etc. for use in further propagating
> the PMTU information.
>
> The destination security gateway and SPI uniquely define a security
> association which in turn defines a set of possible originating
> hosts. At this point, SG1 could:
> a. send the PMTU information to all the possible originating hosts.
> This would not work well if the host list is a wild card or if
> many/most of the hosts weren't sending to SG1; but it might work
> if the SPI/destination/etc mapped to just one host.
Seems to me that if a host wasn't sending to SG1 then it's not an intended
recipient of this PMTU information.
Am I missing something here?
Norm
Norman Shulman Secure Computing Canada
Systems Developer Tel 1 416 813 2075
norm@border.com Fax 1 416 813 2001
References: