Herbert:
Recently the statement
"Implementations MUST process received UDP-encapsulated ESP packets even
when no NAT was detected."
was added to the draft. This has the potential to create black holes if
deployed in the field, unless all implementations always use UDP
encapsulation reg
Yaron:
Additional proposed text for the Security Considerations:
Admission control is critical to the security of the protocol. For example,
IKE trust anchors must be separate from those used for other forms of trust,
e.g. to identify trusted Web servers. Moreover, although IKE provid
Tero:
I think we should mention that the traffic selectors for the rekying should
have those selectors from the packet (see section 2.9):
To allow responder to do intelligent narrowing of the traffic selector
the responder should know which packet triggered the rekeying, so it will
not
Yaron:
2.4: Clarif-7.9 is unclear: [this MUST be sent in the first IKE_AUTH
request.] 'however, receiving parties need to deal with it in other
requests' - what requests? How? Why should it ever happen?
SF discussion:
David Black: if you put initial_contact in anything other than an IKE
Yaron:
Appendix C: please also mention extension notifications [N+], other than in
C.6.
Paul:
Maybe copy it everywhere like we have [V+]
Not discussed in SF.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
I
Hi everyone,
Fresh after shaking off the jet lag from San Francisco, here's a new batch
of IKEv2-bis open issues, all of which we introduced at the face to face
meeting.
Please review them and respond within a week, until April 10.
I have included for each issue the original issue text,
>From Appendix C: The specification does not say which messages can contain
N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is
not yet shown below.
SF discussion: Paul said, "wherever you wish."
smime.p7s
Description: S/MIME cryptographic signature
__
