[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] Comments to the draft-ietf-ipsec-rfc2401bis-02.txt
Tero,
Thanks for your hard work and feedback. Steve's back in the office
in a few days and I'll talk to him then about your comments.
Karen
> > 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
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec