[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ipsec] Comments to the draft-ietf-ipsec-rfc2401bis-02.txt
> 4.4 Major IPsec Databases
> ...
> Multiple Separate IPsec Contexts
> ...
> For example, a security gateway that provides VPN service to
> multiple customers will be able to associate each customer~Os
^^^^
I assume it should be ' there instead of that "~<ctrl-h>O".
> traffic with the correct VPN.
> ...
> 4.4.1.1 Selectors
> ...
> * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, SCTP,
> these selectors is a list of ranges of values. Note that the
> Local and Remote ports may not be available in the case of
> receipt of a fragmented packet, thus a value of OPAQUE also MUST
> be supported. Note: In a non-initial fragment, port values will
> not be available. If a port selector specifies a value other than
> ANY or OPAQUE, it cannot match packets that are non-initial
> fragments. If the SA requires a port value other than ANY or
> OPAQUE, an arriving fragment without ports MUST be discarded.
This thing depends on the fragmentation handling. Support of OPAQUE
should not be mandatory, as it is only needed to support to one of the
fragmentation handling proposals, and that one is most likely going to
be MAY or SHOULD, not MUST.
I propose removing everything after ", thus a value of OPAQUE ..." and
replace it with reference to section 7.
> * If the Next Layer Protocol is a Mobility Header, then there is a
> selector for IPv6 Mobility Header Message Type (MH type) [Mobip].
> This is an 8-bit value that identifies a particular mobility
> message. Note that the MH type may not be available in the case
> of receipt of a fragmented packet, thus a value of OPAQUE MUST be
> supported.
Again makeing the OPAQUE mandatory, where it might not be needed.
Propose removing everyhing after ", thus a value...".
> * If the Next Layer Protocol value is ICMP then there is a 16-bit
> selector for the ICMP message type and code. The message type is
> a single 8-bit value, which defines the type of an ICMP message,
> or ANY. The ICMP code is a single 8-bit value that defines a
> specific subtype for an ICMP message. The message type is placed
> in the most significant 8 bits of the 16-bit selector and the
> code is placed in the least significant 8 bits. This 16-bit
> selector can contain a single type and a range of codes, a single
> type and ANY code, ANY type and ANY code. Given a policy entry
> with a range of Types (T-start to T-end) and a range of Codes (C-
> start to C-end), and an ICMP packet with Type t and Code c, an
> implementation MUST test for a match using
>
> (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end
>
> Note that the ICMP message type and code may not be available in
> the case of receipt of a fragmented packet, thus a value of
> OPAQUE MUST be supported.
Same here.
> ...
> 4.4.1.2 Structure of an SPD entry
> ...
> management interface with the SPD selector "Name".) If the reserved,
> symbolic selector value OPAQUE or ANY is employed for a given
> selector type, only it may appear in the list for that selector, and
> it must appear only once in the list for that selector. Note that
> ANY and OPAQUE are local syntax conventions -D IKEv2 negotiates these
^^^^
Again wierd characters there again...
> ...
> 4.4.2 Security Association Database (SAD)
> ...
> If the protocol is one that has two ports then there will be
> selectors for both Local and Remote ports.
>
> Value in
> Triggering Resulting SAD
> Selector SPD Entry PFP Packet Entry
> -------- ---------------- --- ------------ --------------
> loc port list of ranges 0 src port "s" list of ranges
> or ANY or ANY
> list of ranges 0 no src port discard packet
> or ANY
^^^^^^^^^^^^^
This again depends on the fragmentation processing.
> OPAQUE 0 not avail. OPAQUE
> OPAQUE 1 not avail. ***
> list of ranges 1 src port "s" "s"
> or ANY
> list of ranges 1 no src port discard packet
> or ANY
>
> rem port list of ranges 0 dst port "d" list of ranges
> or ANY or ANY
> list of ranges 0 no dst port discard packet
> or ANY
Same here.
> OPAQUE 0 not avail. OPAQUE
> OPAQUE 1 not avail. ***
> list of ranges 1 dst port "d" "d"
> or ANY
> list of ranges 1 no dst port discard packet
> or ANY
>
> If the protocol is mobility header then there will be a selector for
> mh type.
>
> Value in
> Triggering Resulting SAD
> Selector SPD Entry PFP Packet Entry
> -------- ---------------- --- ------------ --------------
> mh type list of ranges 0 mh type "T" list of ranges
> or ANY or ANY
> list of ranges 0 no mh type discard packet
> or ANY
Same here.
> OPAQUE 0 not avail. OPAQUE
> OPAQUE 1 not avail. ***
> list of ranges 1 mh type "T" "T"
> or ANY
> list of ranges 1 no mh type discard packet
> or ANY
and here. Hmm, I assume also in the ICMP case.
> ...
> 4.5.2 Automated SA and Key Management
> ...
> The default automated key management protocol selected for use with
> IPsec is IKEv2 [Kau04]. Other automated SA management protocols MAY
> be employed.
We should add comment about IKEv1 too. Something like saying that this
document assumes some things from key management protocol which cannot
be done in IKEv1 (ranges, new notifications etc), but limited support
of this document can also be done using IKEv1 for compatibility
reasons.
> ...
> 4.5.3 Locating a Security Gateway
>
> This section discusses issues relating to how a host learns about the
> existence of relevant security gateways and once a host has contacted
> these security gateways, how it knows that these are the correct
> security gateways. The details of where the required information is
> stored is a local matter, but the Peer Authorization Database
> described in Section 4.4 is the most likely candidate.
>
> Consider a situation in which a remote host (H1) is using the
I propose changing H1 to SH1, meaning it is Security Host, and it
knows about IPsec. I had long misunderstandings with people
reading NAT-T drafts as they didn't understand that the HOST A was
talking IPsec, not the NAT box. Using S* prefix for each hosts talking
ipsec cleared up things... So have SH1, SG2, H2 here...
> ...
> 5.1 Outbound IP Traffic Processing (protected-to-unprotected)
> ...
> NOTE: With the exception of IPv4 and IPv6 transport mode, an SG,
> BITS, or BITW implementation MAY fragment packets before applying
> IPsec. The device SHOULD have a configuration setting to disable
> this. The resulting fragments are evaluated against the SPD in the
> normal manner. Thus, fragments not containing port numbers (or ICMP
> message type and code, or Mobility Header type) will only match rules
> having port (or ICMP message type and code, or MH type) selectors of
> OPAQUE or ANY. (See section 7 for more details.)
This is wrong if you are using approach #3. I propose remove
everything from the "Thus, fragments not containing port numbers ..."
to the end of paragraph, and simply add "See section 7 for more
information about fragmentation processing."
> ...
> 5.2 Processing Inbound IP Traffic (unprotected-to-protected)
> ...
> 2. The packet is examined and demuxed into one of three categories:
> - If the packet appears to be IPsec protected and it is addressed
> to this device, an attempt is made to map it to an active SA
> via the SAD.
> - Traffic not addressed to this device, or addressed to this
> device and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD
> lookup. (IKE traffic MUST have an explicit BYPASS entry in the
> SPD.) If multiple SPDs are employed, the tag assigned to the
> packet in step 1 is used to select the appropriate SPD-I (and
> cache) to search.
> - ICMP traffic directed to this device is directed to
> "unprotected" ICMP processing (see Section 6).
We are still missing section 6.... Also there seems to be two ways of
making references, which one is correct "(See Section 6)" above or "[See
Section 6.]" below.
> 3c. Unprotected ICMP processing is assumed to take place on the
> unprotected side of the IPsec boundary. Unprotected ICMP messages
> are examined and local policy is applied to determine whether to
> accept or reject these messages and, if accepted, what action to
> take as a result. For example, if an ICMP unreachable message is
> received, the implementation must decide whether to act on it,
> reject it, or act on it with constraints. [See Section 6.]
^^^^^^^^^^^^^^^^
There.
> ...
> If an IPsec system receives an inbound packet on an SA and the
> packet's header fields are not consistent with the selectors for
> the SA, it MUST discard the packet. This is an auditable event.
> The audit log entry for this event SHOULD include the current
> date/time, SPI, IPsec protocol(s), source and destination of the
> packet, and any other selector values of the packet that are
> available, and the selector values from the relevant SAD entry.
> The system SHOULD also be capable of generating and sending an IKE
> notification to the sender (IPsec peer), indicating that the
> received packet was discarded because of failure to pass selector
> checks.
>
> IKEv2 NOTIFY MESSAGES - ERROR TYPES Value
> ----------------------------------- -----
> INVALID_SELECTORS iana-tbd
>
> This error indication MAY be sent in an IKE INFORMATIONAL
> exchange when a node receives an ESP or AH packet whose
> selectors do not match those of the SA on which it was
> delivered (and which caused the packet to be discarded).
> The Notification Data contains the start of the offending
> packet (as in ICMP messages) and the SPI field of the
> notification is set to match the SPI of the IPsec SA.
This is not the correct document to define IKEv2 notifications. That
text describing the notification is already in the
draft-ietf-ipsec-ikev2-14, so I propose we remove that description of
notification (from IKEv2 NOTIFY MESSAGES - ERROR TYPES to the end of
description), and instead change the text:
"The system SHOULD also be capable of generating and sending an
IKE notification of INVALID_SELECTORS to the sender (IPsec
peer), indicating that the received packet was discarded
because of failure to pass selector checks."
> ...
> 6. ICMP Processing
>
> [This section will be filled in when IPsec issue # 91 is resolved.]
This section is really needed ASAP. At least we need to have the PMTU
processing back, perhaps as separate subsection.
> 7. Handling Fragments (on the protected side of the IPsec boundary)
> ...
> 1. All implementations MUST support tunnel mode SAs that are
Move each approach to separate subsection for easier reference.
> ...
> 3. An implementation MAY/SHOULD support some form of stateful
> fragment checking for a tunnel mode SA with non-trivial port (or ICMP
> type/code or MH type) field values (not ANY or OPAQUE).
> Implementations that will transmit non-initial fragments on a tunnel
> mode SA that makes use of non-trivial port (or ICMP type/code or MH
> type) selectors MUST notify a peer via the IKE NOTIFY payload:
>
> IKEv2 NOTIFY MESSAGES - ERROR TYPES Value
> ----------------------------------- -----
> NON FIRST FRAGMENTS ALSO iana-tbd
Again, no need to define this here, simply give the notify name to be
used. The IKEv2 already defines the number. So remove from the "IKEv2
NOTIFY MESSAGES " to the "iana-tbd", and modify "via the IKE NOTIFY
payload:" to "via the IKE NON_FIRST_FRAGMENTS_ALSO NOTIFY payload.".
> may fail. Also note that stateful fragment checking may create DoS
> opportunities that may be exploitable by hosts on a protected network
> behind a security gateway.
Fragments in general create DoS opportunities. In #1 and #2 there are
opportunities to attack the hosts behind the SGW, in #3 the attack
might be on the SGW, but in that case the attack will only affect the
other fragments, not normal non-fragmented traffic (unless the SGW
implementation is completely broken, and it does not put any limits to
the number of partial fragments it stores).
I do not think this kind of comments gives out any useful information,
and seeing my feedback for the UDP-encapsulation draft, I think the
IESG will want us to explain all possible attacks which might be
exploitable in the SGW because of fragments. This list would of course
be subset of attacks that can be done to any host.
I propose removing that text unless you want to write document
describing all possible fragmentation attacks and put reference to it
here.
> An implementation MAY/SHOULD choose to support stateful fragment
> checking for BYPASS/DISCARD traffic for a tunnel mode SA with non-
> trivial port field values (not ANY or OPAQUE) (Approach 3
> above).
I think we should have text here describing attack of plain text
non-first framgnets. If the recipient is accepting any plain text
packets, it MUST do stateful fragment checking of the BYPASS'ed
non-first fragments. This is regardless of the approach it is using.
I.e. if the recipient have policy that only port 25 (telnet) is
encrypted and authenticated and everything else is bypassed in clear,
then attacker who can see non-first fragment of the packet in the SA
(from SPI for #2, or from the length or similar for #3), can remove
that, and replace it with clear text packet sent to the recipient SGW.
If SGW does not do stateful inspection of the non-first
non-authenticated packet before it BYPASSes it forward the attacker
can now modify the data in the connection. If the SGW DISCARDs the
packet then it really does not care whether it did stateful inspection
or not (i.e. SGW can discard all clear text non-first fragments if it
wants to), but for BYPASS the check is MANDATORY.
I think we need some text there describing that attack, and also
saying that it is MUST to do steteful fragment checking in case of
non authenticated non-first fragments is ever BYPASSed.
> An
> implementation also MUST permit a user or administrator to accept or
> reject BYPASS/DISCARD traffic using the SPD conventions described in
> approaches 1 and 2 above.
I do not really understand what the above text is trying to say?
> ...
> 11. Differences from RFC 2401
>
> [This section will be further updated when things have settled down.
> Issue numbers, status, rejected items, and "proposed changes", etc.
> will be removed in final version. Only the text describing the
> differences from 2401 will remain.]
There are lots of states which are now closed instead of pending or
accepted etc. Those could be fixed, or perhaps this could be already
modified to the final format, i.e. remove the issue numbers etc, and
leave only the text describing the changes.
> ...
> Appendix E -- Fragment Handling Rationale
>
> [Will be added in next draft -- based on write up Steve distributed
> on the list plus subsequent discussion.]
This is missing, perhaps it should be added now, when are closing on
the resolution of the fragmentation issue.
--
kivinen@safenet-inc.com
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec