> >> OK, but if those extra payloads are disguised as some notification > >> (there is no payload actually called “info”), then responders do tend > to ignore notifications they don’t recognize. > > > > True, but in this case the inputs to the hash function will be > > different (you need to insert Notification payload header in the m`), > so the attack will fail. > > I must correct myself - if attacker takes care and puts the Notify > payload header at the end of ck it sends to initiator (and he must > correctly guess the length of info`), then it will work - all the > original payloads from the initiator will appear inside Notification > payload and will be ignored by responder. >
[HJ] how would this work? even attack append a notification header in ck, and return a ck= C1|SAi'|g^x'|ni| notify_header, then m1(from real initiator)=HDR|(C1|SAi'|g^x'|ni| notify_header)_as_ck|SAi|g^x|ni|nat-t, notify header is part of ck, won't be parsed as actual notify payload header. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
