[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-ietf-ipsec-ikev2-00.txt



As for some general comments:
- I'm impressed with the overall integration of RFCs 2407-2409 into a
  single document -- it provides for a compact, single-source
  specification of IKE.
- Would it be possible in just one section of the draft to coalesce
  all timers listed throughout the draft (e.g.: SA Lifetime, timeout
  interval, retransmission interval, proactive rekeying time,
  aliveness checks, etc.), their intended use, their relationship with
  other timers, whether they should/must count upward/downward, etc.?
- As a follow-up to the previous suggestion, why aren't intervals for
  timers at least recommended as SHOULDs in the spec?  Surely, there
  are some timers (e.g.: timeout and retransmission interval) where it
  would be useful to have a common standard among multiple, different
  implementations for "typical" deployment scenario(s).  Is this
  supposed to be left for Informational RFCs or as torture to
  developers/end-users to figure out on their own?  :-)


As for specific comments on the draft itself, here goes:

1.2 Changes from IKEv1

I like this section describing the design goals of IKEv2.  However, it
might also be useful to describe a few of the major similarities IKEv2
has to IKEv1, (e.g.: preserving payload type/formats, error codes,
etc.)


2.1 Use of Retransmission Timers

Just an idea here, is it advisable/recommended that IKE gateways store
RTT values for IKE request/responses, and then potentially use a
multipler of RTT as the Retransmission Interval?

2.2. Use of Sequence Numbers for Message ID

Does it matter if the Message ID integer ALWAYS starts at zero and
increments upward by 1 after each successful transaction?  What I'm
curious about is replay attacks or guessing a predictable sequence
number, as in TCP ISNs, and spoofing messages.  If this is a concern,
should/must Message ID be randomized for its ISN and then increment by
1 after each successful transaction?  In either case, could this be
documented? 

2.4 State Synchronization and Connection Timeouts

   ... An IKE endpoint SHOULD
   send a Delete payload indicating that it has closed the IKE-SA.
Why not a MUST here as well?  This avoids the race condition where one
side falsely thinks an IKE-SA is up and still tries to use the IKE-SA
for some (theoretically finite, but perhaps long) period of time.

2.6 Cookies

   The term "cookies" originates with Karn and Simpson [RFC 2522] in
   Photurus, an early proposal for key managment with IPsec. It has
   persisted because the IETF has never rejected an offer involving
   cookies. 
I like the above humor :-)

My observation is that Paragraph 6 ("It may be convenient for the
IKE-SA identifier ...") seems to be adding more complexity, rather
than promoting the stated goal of reducing it.  Is it too onerous to
get rid of the feature described in Paragraph 6?

2.8 Rekeying

Paragraph 6, "The form of re-keying ...", last sentence:
   The node that initiated the rekeying SHOULD delete the older SA
   after the new one is established.
This is a little vague to me.  Does this mean the initiator should
only delete its local copy of the old SA, and not worry about its
peer?  Or, should the initiator send a DELETE-SA payload to its peer
telling them to delete the old-SA, wait for positive confirmation and
then destroy its local copy of the SA?

2.9 Traffic Selector Negotiation

Could the directionality of IKE-SA's and CHILD-SA's be called out
explicitly in the draft, (e.g.: IKE-SAs are bi-directional and
CHILD-SAs are uni-directional)?  Also, could the reasoning/history for
why IKE-SAs are bi-directional and CHILD-SAs are uni-directional be
documented in the draft?

So, if CHILD-SA's are uni-directional, Traffic Selectors are also
presumably uni-directional as well?  Is there any expectation that
Traffic Selectors exchanged between two peers be symmetric, for
instance to represent a bi-directional conversation between two nodes?

In paragraph 2, "The TS payload consists of a set of individual
traffic selectors ..."  Can a single TS payload simultaneously
represent multiple IPv4 networks + ports under a single SA?
Could you add text clarifying this?


3 The Phase 1 Exchange

Payloads, such as CERTREQ and CERT, can appear 0 or more times in a
particular message.  Which other payloads may appear 1 or more times
in a message?  Regardless, can all payloads be expressed in the
diagrams in Phase 1 + 2 in terms of the number of times they may
appear in a message, perhaps using regular expressions?  If no
payloads may appear more than once, can a brief note be added
indicating such?

[NOTE: if you agree to using regexps to diagram the exchange, then a
new character would have to be chosen instead of '*' to indicate
encrypted IKE messages in further exchanges.  Perhaps parentheses will
be a good indicator of encryption?]

Also, there really are two different SAs in Phase 1 (this section):
IKE-SA (sent in the first round-trip to select transforms, etc. for
IKE) and CHILD-SA (sent during the second round-trip to select
transforms, etc. IPSec).  Can the diagrams and text be cleaned up to
reflect the different SAs?  Perhaps this terminology will do:

(HDR), SAi_ike, KEi, Ni, [,CERTREQi] -->
     <-- (HDR), SAr_ike, KEr, Nr [,CERTREQr]

(HDR), IDi, AUTHi, [CERTi,] SAi_child, TSi, TSr -->
     <-- (HDR), IDr, AUTHr, [CERTr,] SAr_child, TSi, TSr


4 The CREATE-CHILD-SA (Phase 2) Exchange

Third paragraph, second sentence: spelling mistake.  CREAT_CHILD_SA
should be CREATE_CHILD_SA.

4.1 Generating Keying Material for IPsec SAs

There seems to be a discontinuity between the diagrams in section 4
and the text/diagrams in section 4.1.  Specifically, in section 4
Nonces are referred to as Ni, Nr, but in section 4.1 Nonces are
referred to as Ns, Nd.  I'd recommend picking one term and sticking
with it in both sections 4 + 4.1.  

Third paragraph, "In either case, 'protocol', and 'SPI', are from the
SA payload ..."  With respect to protocol, it is also from the SA
accepted by the destination, correct?  If so, could the diagram be
updated to say "protocol_d"?  Second question: what is used for
"protocol_d" if there is multiple protocols -- either a discontiguous
set of protocols or a range of protocols -- specified, and accepted,
in an SA?


5 Informational (Phase 2) Exchange

The diagram re-uses the letter 'N' to signify NOTIFY, whereas above it
signifies a Nonce.  Is it possible to change this as follows:

(HDR), [NOTIFY,]* [DELETE]* -->
			         <-- (HDR), [NOTIFY,]* [DELETE]*

6 Error Handling

First paragraph, last sentence.  You should add that these
informational responses SHOULD be rate-limited (to some reasonable
level), so as not to DoS a potential third-party with an overwhelming
number of, possibly, unsolicited responses.

Referring back to the first paragraph in this section:
   "(e.g. the node is getting ESP messages on a non-existent SPI), the
   node SHOULD initiate an Informational Exchange with a Notify
   payload describing the problem."
... because of the "SHOULD", there could potentially be blackholing of
traffic if one side crashes, reboots, or there is temporary network
congestion/partitioning.  This is one of, if not thee most,
significant problems with IKEv1 today that should get rectified in
IKEv2.  So far, the "birth certificate" proposal seems like the best
remedy to this problem.  Can it be shoehorned in?


7.1 The IKE Header

This is in regards to the difference between the fields contained in
the Generic Payload Header and the sole 'Next Payload' field in the
IKE header.  Aside from the inconsistency between them, how does an
IKEv2 recipient know where the first payload is if there is a
variable-length "Initialization Vector" in the IKE header?  It would
be nice to at least document this fact.  (Note, all other fields in
the IKE header are of fixed length so this seems like the only place
where the recipient needs to store more state and/or do more work to
figure out where is the first IKE payload).

7.2 Generic Payload Header

Just out of curiousity, what was the original reasoning, and the
reasoning today, for the 'Next Payload' field that lists the payload
type for the payload following the present payload, (e.g.: payload+1)?
Why not stick with a simpler TLV encoding that simply references the
payload which immediately follows the payload header?

Also, in what real-world deployment scenarios would the 'Critical' bit
be used in IKEv2?  In particular, this section says the 'Critical' bit
is 0 for all payloads defined in this document [IKEv2] and if it's 0
then the sender doesn't mind if the receiver skips this payload.
(Again, this begs the question of why not use a simpler TLV-encoding
style for payloads and always skip the payloads you don't understand.)

7.3.3 Mandatory Transform Types

The draft currently lists the following mandatory + optional types
that IKE MUST support:
          Protocol  Mandatory Types   Optional Types
            IKE      1, 2, 3, 5, 7
... however, in the "Transform Type Values" section above in section
7.3.2, Transform Type #4 "Integrity Algorithm" seems to be mandatory
for IKE.  Can you update 7.3.3, or 7.3.2, to make this consistent?

7.5 Identification Payload

On SGs that implement Virtual Routers (VRs), it would be useful to
have an additional ID Type designated that could identify the specific
virtual router that the request is sourced from.  The problem is one
chassis may have multiple VRs that all hide behind a single public IP
address.  In addition, each of those VRs may have RFC1918 IP addresses
on the "private" side that overlap with one or more VRs within the
same chassis.  Thus, it's difficult to uniquely ID a specific VR in
IKE.  While it's arguable how to represent a VR in a "standard" way, I
recommend RFC2685 "Virtual Private Networks Identifier" as a possible
solution and recommend creating an ID attribute for it in IKEv2.

7.7 Certificate Request Payload

Last sentence in this section: "If no certificates exist then no
further processing is performed-- this is not an error condition of
the protocol."  I recommend that this be considered an error in
IKEv2, otherwise how is the sender of the CERTREQ going to know
what was the specific problem with it's request?  I recommend the
following language:
   If no certificates exist, no further processing is performed.  A
   NOTIFY MUST be sent to the sender of the CERTREQ informing them of
   this fact using an appropriate error code, (defined below in the 
   "error codes" section of IKEv2 memo).

7.10.1 Notify Message Types

Is it recommended that multiple NOTIFY payloads be packed into a
single Informational exchange?  Or, should multiple NOTIFY payloads be
put in their own, separate IKE messages?

Here are a few more suggestions, which are probably going to be quite
controversial since they go against the grain of re-using as much
of IKEv1 as possible:
1) Is it possible to review and revamp the error-codes in this section
   to perhaps group them and/or make them hierarchical?  For instance,
   it would be nice to, perhaps numerically, indicate error codes
   along the lines of: WHERE-WHY-WHAT.  In other words, which payload
   type(s) caused the problem and what was the problem with them.
   With regard to the "WHERE", it would be nice to break down the
   specific payload type(s) that caused the problem: IKE header,
   generic payload header, SA, proposal, transform, etc.  (If there
   are multiple proposals, then it'd be nice to know the proposal
   number.  In addition, if there are multiple transforms it'd also be
   nice to know the transform number).  With respect to the "WHY", it
   would be useful to break them down into a few different categories:
   INVALID/FATAL, INVALID/INFORMATIONAL, UNSUPPORTED/FATAL,
   UNSUPPORTED/INFORMATIONAL or MALFORMED/FATAL.  Finally, the "WHAT"
   could, if necessary, convey the specific field(s) and/or values in
   those fields that caused the problem.
2) Under Notification Data, I would add: "Upon receiving a NOTIFY
   payload, both the Notification Message Type AND Notification Data
   SHOULD be audited/logged."  Perhaps additional text could be added
   suggesting that most of the time, it is insufficent just to see the
   Notification Message Type to troubleshoot a problem.  Seeing what's
   in the Notification Data, possibly with some interpolation by the
   IKE implementation, will (hopefully) tell the specific reason for
   failure and aid quicker resolution.
3) Aside from sending an error code to the originator, it would be
   _extremely_ useful to also send a list of values/types that the
   receiver supports.  This might be considered a "HOW" appended on to
   the "WHERE-WHY-WHAT" above in suggestion #1.  For instance, if a
   IKE peer sends the NOTIFY payload "INVALID-ID-INFORMATION" it MUST
   also send a list of ID Types that it does support.  This would also
   be extremely useful for the initiator in cases of
   "ATTRIBUTES-NOT-SUPPORTED" and "NO-PROPOSAL-CHOSEN" error codes.
   In short, it's not enough to know that something failed, but also
   how to fix it.

7.13.1 Traffic Selector Substructure

Would it be too much to ask for an addition TS payload that is able to
recognize one or more DS-Byte values?  Presumably, DS-Byte could be
used by itself or in conjunction with IPv4 addresses to provide a
selector into the SPD?

A second question wrt Traffic Selectors is specifying security
services on a single pair of CHILD-SAs for a group of IPv4 addresses
and/or subnets.  Assume the following scenario:

|> private LAN-A <|			     |> private LAN-B <|
192.168.0.0/24 ---+   +------+	  +------+   +--- 192.168.4.0/24
		  |---| SG-A |----| SG-B |---|
192.168.1.0/24 ---+   +------+	  +------+   +--- 192.168.5.0/24

When SG-A and SG-B want to establish a pair of IPSec SAs to protect
all traffic on their private LANs, must they explicitly send all
subnets that comprise the SA inside Traffic Selector payloads?  In
other words, is SG-A required to send 192.168.0.0/24 + 192.168.1.0/24
to SG-B?  Or, can SG-A shortcut this process and send a single summary
network, e.g.: 192.168.0.0/23, or even 0.0.0.0/0 to SG-B?  I recommend
that each subnet of the SA, (e.g.: both /24's), be sent in Traffic
Selectors to avoid any confusion on either end.  Regardless, whaever
is decided, it needs to be called out explicitly in the spec because I
have personally witnessed multiple interpretations by multiple
vendors, which ultimately results in a lack of interoperability.

-shane


Follow-Ups: