dan@MITRE-BEDFORD.ARPA (02/16/88)
This is my second request for information on systems that can handle IP security options. I previously asked about systems that allowed the use of the options. I'd like to expand that request to include systems that will ignore the security options without choking on the datagram. Also, if there are any methods of setting the options on output, I would appreciate hearing about them. Thank you. Daniel Willhite dan@mitre-bedford.arpa
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (02/18/88)
Our PC/TCP accepts datagrams with the security option in them, and ignores it just fine (since December 1987). We presently have no means of setting any options in outgoing IP datagrams. James B. VanBokkelen FTP Software Inc.
karn@thumper.bellcore.com (Phil R. Karn) (02/19/88)
My IP should also correctly ignore any options it doesn't understand. I've never seen a datagram with options, so I can't confirm this for sure, but the code looks right... Phil
tucker%vger@GSWD-VMS.GOULD.COM (Tim Tucker) (02/22/88)
We have found that any system using 4.3 BSD TCP/IP code can't handle the IP security option. The reason follows. If you fragment a packet with the IP security option, the option should only appear in the first fragment. On BSD 4.3 systems this is done correctly, but the IP header in the second or more fragments is too long! The option is removed correctly, but the IP header size is not adjusted. This bug causes fragmented packets with the IP security option to be dropped in reassembly. A big bug, since most people using the option are connected to a link like the ARPAnet thru ethernet. Tim Tucker tucker@claudius.Gould.COM
STJOHNS@SRI-NIC.ARPA (02/22/88)
Umm... the security option is *COPIED* upon fragmentation. Or is supposed to be copied. Check the documentation. Mike
tucker%vger@GSWD-VMS.GOULD.COM (Tim Tucker) (02/22/88)
> Umm... the security option is *COPIED* upon fragmentation. Or > is supposed to be copied. Check the documentation. Mike Ok, your correct. I guess I should say that the problem with the Berkeley code is that it doesn't fragment packets correctly containing IP options that don't get copied to all fragments. By the way, anyone know when the new IP security option RFC will be out? Tim Tucker tucker@claudius.Gould.COM
STJOHNS@SRI-NIC.ARPA (02/22/88)
The new RFC is out. Check the index. Its been out about a month. BUT... contrary to what the document says, it is still not the final form. Specifically, the IDs for the various levels are changing to spread out the coding. *sigh* I'll try and keep you posted as I find out the contortions the BLACKER people are twisting the IPSO into. Mike
postel@VENERA.ISI.EDU (02/23/88)
The IP Security Option must be copied into every fragment of an IP-fragmented datagram. RFC-791 page 18, MIL-STD-1778 page 36, RFC-1038 page 2 --jon.