Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer)

[Daniel Migault <[e-mail]>]

Hi,

Thank you for taking time to review the document and raising the issues. We
noticed they have remained unanswered yet, -- although your points have
probably helped us clarifying the document. This email's intention is to
address the issue you raised. Feel free to let us know whether you agree on
the response or if you woudl like additional information.

BR,
Daniel

%%%
ISSUE 1 : when is the ‘CLONE_IKE_SA’ notification exactly sent - perhaps
some examples (e.g. uplink route comes up)?

RESPONSE 1: The draft explicitly mentions two use cases, the mobility use
case and the load sharing use case. Both use cases have been detailled and
Appendix A provides diagrams and figures to detail step by step the
mobility use case.

%%%
ISSUE 2: please consider good integration with ‘Session Resumption’.
particularly as a ‘low-cal’ extension to section 4.3.3, someone alluded to
this earlier.

RESPONSE 2: The Clone IKE SA mechanism is outside Session Resumption, so
Session Resumption is not an issue for this draft.

%%%
ISSUE 3: please consider consistency with the ‘ADDITIONAL_IP*_ADDRESS list,
someone alluded to this earlier.

RESPONSE 3: The Clone IKE SA mechanism use MOBIKE, but does not extend it
and so remains outside MOBIKE. Interactions with ADDITIONAL_IP*_ADDRESS is
not an issue for this draft.

%%%
ISSUE 4: perhaps, a (configurable) maximum lifetime for the series of
cloned IKE_SAs?
RESPONSE 4: The IKE_SA life time negociation is not part of the IKEv2:
RFC7296 section 2.8 mentions

"A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were
negotiated.  In IKEv2, each end of the SA is responsible for enforcing its
own lifetime policy on the SA and rekeying the SA when necessary.  If the
two ends have different lifetime policies, the end with the shorter
lifetime will end up always being the one to request the rekeying.  If an
SA has been inactive for a long time and if an endpoint would not initiate
the SA in the absence of traffic, the endpoint MAY choose to close the SA
instead of rekeying it when its lifetime expires.  It can also do so if
there has been no traffic since the last time the SA was rekeyed."

%%%
ISSUE 5: What should be done for extraneous ‘CLONE_IKE_SA’ notifications?
RESPONSE 5: This has been adressed in section 5.2 of the current draft.

"The CLONE_IKE_SA notification MUST appear only in request message of the
CREATE_CHILD_SA exchange concerning the IKE SA rekey. If the CLONE_IKE_SA
notification appears in any other message, it MUST be ignored."


On Wed, Dec 3, 2014 at 7:09 AM, Les Leposo <[e-mail]> wrote:

> Hi All,
>
> there probably are gateways that currently perform ‘faux-cloning IKE-SAs’
> (e.g. through data replication tricks) - if so, they would only have an
> opportunity to do so upon receiving favourable UPDATE_SA_ADDRESSES
> notifications. I’m not sure if clients do this sort of thing.
>
> So, I support this draft because it could help standardise how ‘low-cal’
> clients & distributed servers hand-over tunnels. It can also be used to
> improve handovers, but, it potentially introduces some security risks.
>
> This draft is like __builtin_prefetch - it can be great if used
> effectively, otherwise it could get a little worse.
>
> A few issues:
> 1) when is the ‘CLONE_IKE_SA’ notification exactly sent - perhaps some
> examples (e.g. uplink route comes up)?
> 2) please consider good integration with ‘Session Resumption’.
> particularly as a ‘low-cal’ extension to section 4.3.3, someone alluded to
> this earlier.
> 3) please consider consistency with the ‘ADDITIONAL_IP*_ADDRESS list,
> someone alluded to this earlier.
> 4) perhaps, a (configurable) maximum lifetime for the series of cloned
> IKE_SAs?
> 5) What should be done for extraneous ‘CLONE_IKE_SA’ notifications?
>
>
> > On Dec 3, 2014, at 2:20 AM, [e-mail] wrote:
> >
> > Send IPsec mailing list submissions to
> >       [e-mail]
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >       https://www.ietf.org/mailman/listinfo/ipsec
> > or, via email, send a message with subject or body 'help' to
> >       [e-mail]
> >
> > You can reach the person managing the list at
> >       [e-mail]
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of IPsec digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re: Survey for WG interest in adopting
> >      draft-nagayama-ipsecme-ipsec-with-qkd (Yaron Sheffer)
> >   2. Re: Survey for WG interest in adopting
> >      draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer)
> >   3. Re: Survey for WG interest in adopting
> >      draft-nagayama-ipsecme-ipsec-with-qkd (Rodney Van Meter)
> >   4. Re: Some speculations about puzzles (Graham Bartlett (grbartle))
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 02 Dec 2014 23:19:39 +0200
> > From: Yaron Sheffer <[e-mail]>
> > To: Paul Hoffman <[e-mail]>, IPsecME WG <[e-mail]>
> > Subject: Re: [IPsec] Survey for WG interest in adopting
> >       draft-nagayama-ipsecme-ipsec-with-qkd
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > Here's a quick reminder to speak up if you're interested in this
> > document and are willing to contribute as co-author or reviewer.
> >
> > Thanks,
> >       Yaron
> >
> > On 11/25/2014 10:06 PM, Paul Hoffman wrote:
> >> <chair hats on>
> >>
> >> Greetings again. There is a small emerging industry of crypto solutions
> that transmit keys using Quantum Key Distribution (QKD), and then use those
> keys for classical high-speed encryption. Several such solutions are using
> IKE, and there is a perceived need to standardize this usage. If so, that
> standardization should be done in this Working Group.
> >>
> >> If you agree with the need to standardize this usage, and believe that
> draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place
> for that standardization, and are willing to review and contribute text to
> the document if it is adopted by the WG, please say so on the list. This WG
> has a history of adopting documents but then not having enough reviewers
> for us to feel confident that we are making a good standard, so we need to
> see a reasonable number of actively interested people before we adopt the
> document. If it is not adopted, the authors can ask for it to be published
> as an RFC through individual submission or by the Independent Submissions
> Editor.
> >>
> >> Please reply by December 8, 2015.
> >>
> >> --Paul Hoffman and Yaron Sheffer
> >> _______________________________________________
> >> IPsec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >>
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 02 Dec 2014 23:20:33 +0200
> > From: Yaron Sheffer <[e-mail]>
> > To: Paul Hoffman <[e-mail]>, IPsecME WG <[e-mail]>
> > Subject: Re: [IPsec] Survey for WG interest in adopting
> >       draft-mglt-ipsecme-clone-ike-sa
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset=utf-8; format=flowed
> >
> > And similarly for this draft: please speak up if you're interested in
> > this document and are willing to contribute as co-author or reviewer.
> >
> > Thanks,
> >       Yaron
> >
> > On 11/25/2014 10:06 PM, Paul Hoffman wrote:
> >> <chair hats on>
> >>
> >> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA
> setup in cases where VPN gateways have multiple interfaces and want to
> establish different SAs on the different interfaces without having to
> repeat the IKE authentication. Instead, they could clone a single IKE SA
> multiple times, and then move it to different interfaces using MOBIKE.
> >>
> >> If you agree with the need to standardize this usage, and believe that
> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for
> that standardization, and are willing to review and contribute text to the
> document if it is adopted by the WG, please say so on the list. This WG has
> a history of adopting documents but then not having enough reviewers for us
> to feel confident that we are making a good standard, so we need to see a
> reasonable number of actively interested people before we adopt the
> document. If it is not adopted, the authors can ask for it to be published
> as an RFC through individual submission or by the Independent Submissions
> Editor.
> >>
> >> Please reply by December 8, 2015.
> >>
> >> --Paul Hoffman and Yaron Sheffer
> >> _______________________________________________
> >> IPsec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >>
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 2 Dec 2014 17:49:58 -0500
> > From: Rodney Van Meter <[e-mail]>
> > To: Yaron Sheffer <[e-mail]>
> > Cc: Rodney Van Meter <[e-mail]>, IPsecME WG
> >       <[e-mail]>, Paul Hoffman <[e-mail]>
> > Subject: Re: [IPsec] Survey for WG interest in adopting
> >       draft-nagayama-ipsecme-ipsec-with-qkd
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset=utf-8
> >
> > Hi,
> >
> > Sorry to be a little slow to reply.  I was offline over Thanksgiving,
> just saw the messages yesterday afternoon.
> >
> > Of course I favor adoption, and am willing to work with anyone who can
> contribute to the development of an appropriate protocol.  Momentum seems
> to be toward a version supporting a variety of out-of-band mechanisms, and
> I?m willing to work in that direction.
> >
> > Shota is looking in to the numerous issues I detailed in the long
> message right after IETF.
> >
> >               ?Rod
> >
> >> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer <[e-mail]>
> wrote:
> >>
> >> Here's a quick reminder to speak up if you're interested in this
> document and are willing to contribute as co-author or reviewer.
> >>
> >> Thanks,
> >>      Yaron
> >>
> >> On 11/25/2014 10:06 PM, Paul Hoffman wrote:
> >>> <chair hats on>
> >>>
> >>> Greetings again. There is a small emerging industry of crypto
> solutions that transmit keys using Quantum Key Distribution (QKD), and then
> use those keys for classical high-speed encryption. Several such solutions
> are using IKE, and there is a perceived need to standardize this usage. If
> so, that standardization should be done in this Working Group.
> >>>
> >>> If you agree with the need to standardize this usage, and believe that
> draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place
> for that standardization, and are willing to review and contribute text to
> the document if it is adopted by the WG, please say so on the list. This WG
> has a history of adopting documents but then not having enough reviewers
> for us to feel confident that we are making a good standard, so we need to
> see a reasonable number of actively interested people before we adopt the
> document. If it is not adopted, the authors can ask for it to be published
> as an RFC through individual submission or by the Independent Submissions
> Editor.
> >>>
> >>> Please reply by December 8, 2015.
> >>>
> >>> --Paul Hoffman and Yaron Sheffer
> >>> _______________________________________________
> >>> IPsec mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ipsec
> >>>
> >>
> >> _______________________________________________
> >> IPsec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ipsec
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 2 Dec 2014 23:20:33 +0000
> > From: "Graham Bartlett (grbartle)" <[e-mail]>
> > To: Valery Smyslov <[e-mail]>, Yoav Nir <[e-mail]>,
> >       ipsec <[e-mail]>
> > Subject: Re: [IPsec] Some speculations about puzzles
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi Valery
> >
> > Would the Timestamp be generated every time cycle? If this wasn't a
> static
> > figure (per timecycle - maybe when the secret is changed?, but rather a
> > rolling unix time), then how would the Responder be able to validate this
> > Cookie (without trying every previous timestamp or having the timestamp
> > included in the Initiators reply?). Would it not be better to save X
> > number of Secrets and just try them instead (assuming that the Secret is
> > changing fairly regularly)? The Secret could also be used to tell
> (approx)
> > how old the Cookie is.
> >
> >
> > I like the two options of the header in the clear.
> >
> >
> > Many thanks
> >
> > On 01/12/2014 15:34, "Valery Smyslov" <[e-mail]> wrote:
> >
> >> Hi, this is a long message.
> >>
> >> First of all I think that the puzzles mechanism is a great tool
> >> to make DoS attacks harder for attackers and we should
> >> try to incorporate it into IKE. Moreover, I think that
> >> the puzzles could be used not only in IKE_SA_INIT, but also
> >> to defend against DoS attacks in IKE_AUTH exchange (see below).
> >> However, the puzzles mechanism is a controversal thing,
> >> since it requires an additional work from legitimate clients.
> >> It could be particularly troublesome for small battery-powered wireless
> >> devices (smartphones, IoT devices etc) - not only would it delay
> >> connection
> >> setup, but it also would decrease battery lifetime.
> >>
> >> So think that the puzzles mechanism if incorporated into IKE should
> follow
> >> some general principles:
> >> 1. Puzzles should be optional. It should be possible for client to just
> >> return
> >>   cookie even if puzzle is given by SGW).
> >> 2. The ultimate decision whether to solve puzzle or ignore it should be
> >> made
> >> by client.
> >> 3. Those, who ignore puzzles (for any reason - either they are legacy
> >> clients
> >>   or they decide to save battery) should still have a chance to setup
> >> connection
> >>   (on "best effort" basis).
> >>
> >> In other words, let's consider puzzles mechanizm not as discriminating
> >> tool
> >> ("those who cannot solve puzzles won't be allowed in"), but as
> >> a "first-class ticket" for those, who are ready to pay for it.
> >> And the price for the first-class service should be high enough to make
> it
> >> unattractive for attackers.
> >>
> >>
> >> Concrete proposals.
> >>
> >> 1. Algorithm agility for puzzles. It is relatively easy to achieve. When
> >> IKE_SA_INIT request comes from the client, the server could quicly parse
> >> it,
> >> find SA payload and figure out the list of transforms the client
> proposes.
> >> Then it could select mutually supported PRF and indicate it to the
> client
> >> in response containing puzzle. The puzzle in this case would look like:
> >> "please, give me a string of octets such, that if this PRF is applied
> >> to that string of octets using supplied cookie as the key, then the
> >> result would contain this number of trailing zero bits" (another option
> -
> >> apply PRF to cookie + string of octets using zero key).
> >>
> >> Parsing IKE_SA_INIT message is a relatively easy task.
> >> The side advantage of this approach is that the server
> >> could quickly check the structure of the message and
> >> the list of proposed transforms and wouldn't spend more resources
> >> in case the initial message is malformed or no proposals are acceptable
> >> to the responder.
> >>
> >> 2. Cookie generation. Currently RFC7296 suggestd the following
> >> formula to compute cookie:
> >>
> >>   Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
> >>
> >> With puzzles more information should be present in the cookie
> >> to prevent some attacks from initiator. First, when
> >> responder asks initiator to solve the puzzle, it sets puzzle
> >> difficulty to some level and indicates it in the response message.
> >> When the solved puzzle is returned back to the responder,
> >> it must know in a stateless manner what level of difficulty
> >> it has requested. Otherwise the initiator could cheat. So responder
> >> must encode this information into cookie, as the cookie is an entity
> that
> >> initiator cannot forge. Then, it is desirable to also include
> >> timestamp into cookie to prevent initiator from re-using solved puzzles
> >> and from collecting a lot of puzzles, solving them and then presenting
> >> them
> >> all at once. Including timestamp allows the responder
> >> to determine how old this cookie is and, therefore,
> >> how much time it was taken from the initiator to solve the puzzle.
> >> If the results are suspicious (an easy puzzle took too long to be
> solved),
> >> then the request should be rejected, even in the case it contains
> >> a valid solution for the puzzle. And in case of accepting
> >> algorithm agility method described above the selected PRF
> >> must also be encoded in cookie.
> >>
> >> So, the cookie generation would look like:
> >>
> >>   Cookie = <VersionIDofSecret> | <Timestamp> | <PuzzleDifficulty> |
> >> <PRF>
> >> |
> >>       Hash(Ni | IPi | SPIi | <Timestamp> | <PuzzleDifficulty> | <PRF> |
> >> <secret>)
> >>
> >> Note, that <PuzzleDifficulty> should be allowed to be zero here -
> >> in case it is just a cookie request with no puzzle request.
> >>
> >> To summarize here is a possible sequence of messages in IKE_SA_INIT:
> >>
> >>  request             --> HDR, SA, KE, Ni,
> >>                          [N(NAT_DETECTION_SOURCE_IP)+,
> >>                           N(NAT_DETECTION_DESTINATION_IP),]
> >>                          [V+][N+]
> >>
> >>  response with puzzle    <-- HDR, N(COOKIE), N(PUZZLE, PRF=<X>,
> >> DIFFICULTY=<N>)
> >>                          [V+][N+]
> >>
> >> Legacy client or client that don't want to spend recources on puzzle
> >> would ignore N(PUZZLE) and act as if only N(COOKIE) was received.
> >>
> >>  request             --> HDR, [N(COOKIE),]
> >>                          SA, KE, Ni,
> >>                          [N(NAT_DETECTION_SOURCE_IP)+,
> >>                           N(NAT_DETECTION_DESTINATION_IP),]
> >>                          [V+][N+]
> >>
> >> At this point the responder will:
> >> - check that the cookie is valid
> >> - retrieve timestamp and difficulty level from the cookie and ensures it
> >> is
> >> fresh for that level
> >> - if the level is zero, then it means that no puzzle was requested
> >> - if the level is non-zero then it means that the initiator either
> >> doesn't support puzzles or is unwilling to solve them; in either
> >> case the request is processed on "best effort" basis -
> >> it could be served or dropped depending on current resource availability
> >> or on some probability (e.g.serve every Nth request in case of attack)
> >>
> >> Client, that is solved the puzzle:
> >>
> >>  request             --> HDR, [N(COOKIE),], N(PUZZLE_SOLUTION)
> >>                          SA, KE, Ni,
> >>                          [N(NAT_DETECTION_SOURCE_IP)+,
> >>                           N(NAT_DETECTION_DESTINATION_IP),]
> >>                          [V+][N+]
> >>
> >>
> >> At this point the responder will:
> >> - check that the cookie is valid
> >> - retrieve timestamp and difficulty level from the cookie and ensures it
> >> is
> >> fresh for that level
> >> - if the level is zero, then it means that no puzzle was requested,
> >> but initiator still supplied some solution; in this case
> >> N(PUZZLE_SOLUTION)
> >> is ignored and the message is processed as described above
> >> - if the level is non-zero then responder will retrieve PRF from the
> >> cookie
> >> and verify the correctness of supplied puzzle solution
> >> - if everything is OK then this request is served with higher priority
> >>
> >>
> >> 3. Using puzzles in IKE_AUTH exchange. The draft
> >> ipsecme-ddos-protection-00
> >> describes DoS attack on IKE_AUTH exchange:
> >>
> >>      Sending an Authentication request is surprisingly cheap.  It
> >> requires
> >>      a proper IKE header with the correct IKE SPIs, and it requires a
> >>      single encrypted payload.  The content of the payload might as well
> >>      be junk.  The responder has to perform the relatively expensive key
> >>      derivation, only to find that the Authentication request does not
> >> decrypt.
> >>
> >> I think that the puzzles could be used to make this attack substantially
> >> more expensive for the attacker. The idea is to require the initiator
> >> to supply an additional string of octets in IKE_AUTH request such, that
> >> applying PRF with the Nr as the key to this string of octets
> >> concatenated with the content of the IKE_AUTH message will
> >> result in some number of zero trailing bits. In this case if the
> attacker
> >> fills in the content of SK payload with garbage, it will be detected
> >> by the responder without performing DH computation. The level of
> >> difficulty
> >> in this case must be set so, that the time needed to solve the puzzle is
> >> by the order of magnitude more, than to compute DH, so that
> >> this attack becomes unattractive for potential attacker.
> >>
> >> There are some options where to place puzzle solution
> >> in IKE_AUTH message.
> >>
> >> 1. It could be explicitely present as Notification payload
> >>     before Encrypted payload:
> >>
> >>      HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CERTREQ,]
> >>      [IDr,] AUTH, SAi2, TSi, TSr}
> >>
> >> 2. It could be placed right after Encrypted payload without
> >>     any header. In this case the length indicated in IKE Header
> >>     would be greater, than the length indicated in Encrypted payload
> >>     header, and the solved puzzle would be placed in this gap.
> >>
> >>      HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr}
> >> <solved
> >> puzzle>
> >>
> >> In case of IKE fragmentation every fragment should contain
> >> its own solution for the puzzle. Note also, that puzzles in IKE_AUTH
> >> are mandatory for initiator if they are requested by responder -
> >> the request won't be processed untill the initiator provides
> >> puzzle solution (this is unlike puzzles in IKE_SA_INIT, where
> >> they should be optional).
> >>
> >>
> >> Regards,
> >> Valery Smyslov.
> >>
> >> _______________________________________________
> >> IPsec mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ipsec
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: smime.p7s
> > Type: application/pkcs7-signature
> > Size: 3708 bytes
> > Desc: not available
> > URL: <
> http://www.ietf.org/mail-archive/web/ipsec/attachments/20141202/b7299f72/attachment.p7s
> >
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
> >
> >
> > ------------------------------
> >
> > End of IPsec Digest, Vol 128, Issue 2
> > *************************************
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>