Scott C Moonen writes:
> > > > We've interpreted it as follows: 1) the old IKE SA's PRF is used to
> > > > produce SKEYSEED, but 2) the new IKE SA's PRF is used to produce
> SK_x.
> > >
> > >Hmm... when reading my code, it seems I do the same, but when I read
> > >the text I interpreted it differe
Yaron Sheffer writes:
> I think Tero's text is somewhat speculative in assuming that this
> error case only results from exhaustion of the address pool - I'm
> sure there can be other reasons. Otherwise the text is OK.
Can you give me example what other error causes can cause this error
notificati
No, I don't have a good example. But the error code is not reserved
specifically for this situation, so I wouldn't want to imply that it is.
Anyway, I'm OK with your text and also with the text that Paul proposed earlier.
Thanks,
Yaron
> -Original Message-
> From: Tero Kivinen
Hi Alper,
It seems that your argument goes to 3GPP only not this new work item,
then I would suggest that you propose your solution to 3GPP HNB.
Back to your questions, the scenarios is that some user need this IKE/IPsec
or other don't need IPsec for the first, and also could be upgraded to
need
I'm not done my review, but here are the observations -- all minor -- that
I've got so far:
Section 1.2, paragraph 2 -- "the identities are hidden from
eavesdroppers". Is it worth noting that a man-in-the-middle could
intrusively discover the initiator's identity?
Section 1.3.1 -- "When an IK
Hi Hui,
> Hi Alper,
>
> It seems that your argument goes to 3GPP only not this new work item,
> then I would suggest that you propose your solution to 3GPP HNB.
We are having this discussion in IETF right now. So, there is no point in
telling us to go elsewhere. If the discussions is here, it is
>Section 1.2, paragraph 2 -- "the identities are hidden from eavesdroppers".
>Is it worth noting that a man-in-the-middle could intrusively discover the
>initiator's identity?
Added: (A man-in-the-middle who cannot complete the IKE_AUTH exchange can
nonetheless see the identity of the initiato
Section 1.3.1 says "When an IKE SA is not created, the error message return
SHOULD NOT be encrypted because the other party will not be able to
authenticate that message." First, this seems out of place, since this section
talks about CREATE_CHILD_SA for Child SAs. Second, assuming this is tal
