IETF 116 - Wednesday March 29th, 2023 15:30-17:00 JST
https://meetings.conf.meetecho.com/ietf116/?group=ipsecme&short=&item=1
Work items
AOB + Open Mic (0 min)
Chairs
Chairs
Paul Wouters
(slide 4)
Valery: can we use both proposals for deciding what groups to use for
PFS? Paul argued for proposal 1.
(slide 5)
Yoav: for IPsec-type notifies, Yaov argued for proposal 2 (???)
Valery: he argued for proposal 1
Tero: (referring back to slide 4) put the notifies in the same place
where we put other notifies related to SAs, i.e. rfc7296 says they are
in same message where the SA payload is.
(slide 6)
Scott: another proposal is to just not support IPComp.
Paul: well, this is not the place for deprecating IPComp.
Yoav: we (checkpoint) didn't have IPComp but we had single-DES!
(slide 7)
Valery: if the peers don't agree it's a failure
Paul: but you don't need to tear down IKE SA if child SA has negotiation
issue.
Paul: discuss on list further.
appeal for more than 2 implementations....
(slide 5)
Tero: GIKEv2 actually uses the wrapping keys, and if I remember right
the key for wrapping is derived in such way it gets PPK protection.
Tero: there may be an issue if the two sides have different PPKs (with
the same PPKID). Should be easy to fix.
Scott: you assume the peer supports 8784 and this protocol, that may not
be the case.
Valery: if controller doesn't understand this then it's negotiatable.
Scott: if the controller doesn't understand it's not gonna do the right
thing.
Valery: then it will do 8784.
Scott: need another NOTIFY to say you support this particular protocol.
Paul: you would have the same 2 NOTIFYs-- bad.
(slide 8)
Paul: this could be accidentally done
Valery: we could forbid it
(slide 9)
Tero: we would need to send multiple key confirmation payloads. And, are
we reusing the authpayloads, how do we tie them together - details need
to be worked out
Michael: instead of a payload, you could use a computed id
Tero action: this will be a working group item, should start wg adoption
call soon.
Valery Smyslov
Daniel: the changes are so extensive, you might as well call it IKEv3
Yaov: we're actually solving two problems: large payloads, and trying to
compactify things. These are two different problems; perhaps they should
be solved separately.
Scott: the rules to send large payloads is straightforward and the
compactify stuff is more complicated. Maybe leave rest to IKEv3.
Tero: are you touching anything outside of the payloads? If not, it
might be a way to automatically convert from the standard IKEv2 format
and the compressed format.
Tero: before the WG works on this, we need more mailing list comments
Poll: 12 votes to support > 64k payloads, 1 not to
Paul: Perhaps we should wait before going ahead to support huge
payloads.
Mohsin Shaikh
Q: should the group adopt this?
Ben: it's an interesting topic and the WG should deal with it. Draft is
a reasonable starting point.
Paul: the IPR is a standard release
Dan: Network Alchemy may have old IPR in this area
Daniel Migault
Tero: I propose that we wait for more people to comment on the list
Daniel Migault
Tero: what is the benefit? Does it make management easier?
Tero: I see the traffic DSCP selector associated with the initiator
Valery: DSCP is not a security property - should this be a part of the
traffic selector?
Valery: DSCP list reduction by the responder might not work property.
Paul: if you negotiate one SA with some of the DSCPs, and send traffic
not matching that DSCP, we'll send that traffic in the clear - not good.
Yoav: didn't have time for this but we will devote time in the future.
Paul: need routing people involved too, not just ipsec people.