[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC Arch, ports, and tunnel mode SAs
I have a question regarding the following change to the IPSEC Arch and
a tunnel mode SA(s) set up between two SG's.
Can I set up a tunnel mode SA between two SGs where one of the
(outbound) selectors is a protocol port? If so, what do I do when I
receive an IP fragment on my "non-IPSEC" side? I can't determine
which tunnel to send through since I may not have the port info.
Or, is the decision to forward fragments dependent on what I have in
the ports field of the selector. That is if the port fields are set
to "don't care", then I can send fragments. But, if they are set to
specific values, then I must drop fragments.
It seems like a bad idea to me to allow ports as a selector if it
means that we can't send ip fragments through the tunnels. (you might
extend this statement and say it is a bad idea to allow ports as a
selector for tunnel mode SAs.)
- chrisb
This didn't clear it up for me:
> * Changed the paragraph on "Source and Destination (e.g.,
> TCP/UDP) Ports" from:
> [REQUIRED for all implementations]
> to:
> [MAY be supported]
>
> * Added text at the end of the paragraph on "Source and
> Destination (e.g., TCP/UDP) Ports"
>
> The following table summarizes the relationship between the
> "Next Header" value in the packet and SPD and the derived Port
> Selector value for the SPD and SAD.
>
> Next Hdr Next Hdr Derived Port Selector Field
> in Packet in SPD Value in SPD and SAD
> -------- -------- ---------------------------
> ESP ESP or ANY ANY (i.e., don't look at it)
> -don't care- ANY ANY (i.e., don't look at it)
> specific value specific value NOT ANY (i.e., drop packet)
> fragment
> specific value specific value actual port selector field
> not fragment
>
> If the packet has been fragmented, then the port information
> may not be available in the current fragment. If so, discard
> the fragment. An ICMP PMTU should be sent for the first
> fragment, which will have the port information.
--
Chris Boscolo chris.boscolo@WatchGuard.com
WatchGuard Technologies (206) 521-8348
Follow-Ups: