[IPsec] Comments to draft-nir-ipsecme-cafr-02
In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the document lists operations which needs to be done when handling the notification. The process seems otherwise quite good, expect the error handling seems to be bit drastic. It currently says that if the authenticated identites are different then other end replies with INVALID_SYNTAX error message: -- 2.2. Verifying the HAND_OVER_CHILD_SAS Notification ... o The authenticated identities of both sides under the new IKE SA are the same as those under the old IKE SA. If the authenticated identity of one peer differs from the authenticated identity that it had in the previous IKE SA, the other side MUST respond with an INVALID_SYNTAX notification. ... -- >From RFC5996, the INVALID_SYNTAX processing is described as following: -- 2.21.3. Error Handling after IKE SA is Authenticated ... If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit Delete payload. -- I.e. the INVALID_SYNTAX notification is considered fatal in both peers, meaning that IKE SA is deleted. In this case this will cause the OLD IKE SA to be deleted. I do not think we want to be that to happen. Perhaps something less fatal error message would be better as this is not error cases listed in the RFC5996: "message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons." (Ok, it could be considered to be rejected because policy reasons). As we are moving CHILD SAs, perhaps we could consider this as normal "Generic Child SA error" and use NO_PROPOSAL_CHOSEN. Also in the end of the section 2.2 it says: -- If the Initiator has sent the notification, but the notification from the Responder does not match the IKE SPIs in the Initiator's notification, the Initiator MUST send a SYNTAX_ERROR notification and MUST NOT transfer the Child SAs. -- but there is no SYNTAX_ERROR error message in the IKEv2. This on the other hand is clearly fatal error, as it indicates that the responder has somehow corrupted its state, or there is implementation bug there, if it cannot copy SPI from the request to the reply properly. On the other hand I see no reason why the reply should include the SPI it all. It would be better that initiator just sends the notify with the SPI, and responder replies with the notify and does not include SPI at all (i.e. its notify data would be empty). The SPI in the responder message does not have any meaning or use. In section 7 Security Considerations I can see the attack that can happen if the authenticated identities are not same. I.e. if host uses authenticated identities also outside the IPsec. For example the host might export the authenticated identities to the nfs-server, and nfs-server could use that to verify what kind of operations the user can do. In that case attacker might create IKE SA and Child SA to nfs-server of the server, and then move the Child SA to another users IKE SA, and then start doing nfs-requests. Now when nfs-server asks from the IPsec engine who is on the other end of the protected IPsec tunnel the IPsec engine would respond wrong users... As long as the IPsec is mostly used for VPNs this kind of setups are not used, but if host to host IPsec ever comes reality this kind of setups might happen, so I think that check is very important... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
Valery Smyslov writes: > There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number > and Total Fragments. But Total Fragments field plays a dual role if > peer uses PMTU discovery - i.e. tries several fragment sizes. > In this case Total Fragments allows to distinguish between fragments from > different sets (assuming that trying smaller fragment size results in > increasing number of fragments). This was the thing that confiused me when reading the document. The section 2.5 should explain the Total Fragments much better. I.e. change the definition something like: o Total Fragments (2 octets) - number of fragments original message was divided into. If original message is resent with different fragmentation boundaries this value MUST be larger than the previously used Total Fragments value, i.e the responder will use this to detect whether the incoming message belongs to the group of packets fragmented in same way. This field MUST NOT be zero. Or something like that. Also I do not understand why the Fragment Number and Total Fragments start from 1. I think it would be more logical to have first fragment be 0, second 1, and the Total Fragments would be The Last Fragment# field. That way we do not need to have special check that fragment needs to be ignored if Fragment Number or Total Fragments are 0. In general I think the sending and receiving rules should be explained a bit more. For example the o Check message validity - in particular, check whether values of Fragment Number and Total Fragments in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. should be changed to say: o Check message validity - in particular, check whether values of Fragment Number (must be <= Total Fragments) and Total Fragments (must be >= previously seen Total Fragments for this message) in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. It should clearly say that if Total Fragments is less than previously seen then this fragment needs to be discarded. Now when I am reading th text several times through I see that all the required things are there, but when I was reading it first time through it was really hard to parse what is going on, and especially as I missed the dual role of the Total Fragments I got confused. It might be enough to just add more text in the Total Fragments description, clearly stating that it has dual role, i.e. telling what is the max fragment number of this message, and to separate the different fragmentation boundaries. My text above does not yet properly describe that either, so some better text is needed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
On Wed, 9 Oct 2013, Tero Kivinen wrote: For example the o Check message validity - in particular, check whether values of Fragment Number and Total Fragments in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. should be changed to say: o Check message validity - in particular, check whether values of Fragment Number (must be <= Total Fragments) and Total Fragments (must be >= previously seen Total Fragments for this message) in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. It should clearly say that if Total Fragments is less than previously seen then this fragment needs to be discarded. But you must only do that after the decryption/authentication of the fragment or we are back at square one with an easy DoS this whole mechanism was supposed to protect us from. Which of course means an attacker can just send crap faster that you can verify it is crap after performing crypto on the fragment. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details
Paul Hoffman wrote: > The call-in details are: > Tele: +1 712-775-7400 > Code: 809604# Two LD suppliers (entirely different phones) tell me that I can not reach this number from my line. I'm gonna try Google Talk now. (and I guess it's really in an hour anyway) -- Michael Richardson , Sandelman Software Works pgpA0K1Xmn2Zm.pgp Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details
Michael Richardson wrote: >> The call-in details are: >> Tele: +1 712-775-7400 >> Code: 809604# mcr> Two LD suppliers (entirely different phones) tell me that I can not reach mcr> this number from my line. I wonder if this exchange has an inflated LD rate? Nice if there was a SIP option to reach them how does that ENUM RR work again :-) mcr> I'm gonna try Google Talk now. GoogleTalk connected. -- Michael Richardson , Sandelman Software Works pgpkKSsyg0XU0.pgp Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments to draft-song-ipsecme-seq-icv-01
The new SEQ-ICV calculation is no more safer than the previous one. It
is trivial to break it:
SEQ-ICV = (SEQ + ICV[0-3]) ^ K[0-3] +
(SEQ + ICV[4-7]) ^ K[4-7] +
(SEQ + ICV[8-11]) ^ K[8-11]
The problem is that lowest byte of the SEQ-ICV only depends on the
K[3] + K[7] + K[11], as the SEQ and ICV is known to the attacker. So
attacker needs to do O(2^24) work to crack the 3 bytes from the key.
For the next 3 bytes it needs to do same, and so on. So the total
complexity of the SEQ-ICV is O(4*2^24) = O(2^26), i.e. around 67
million tries. In my attacked perl script the cracking can be done
after seeing around 50 packets with valid SEQ, ICV, SEQ-ICV triplets,
and the main reason it requires 50 packets is that I try 10 packets
before I am convinced that my guess for the 3 bytes is correct before
moving to the next byte, so 4 * 10 == 40 would be the mimimum... The
run time of my attack script is less than 20 seconds... And time to
implement that script was around an hour, inventing the method to
start attacking against it took less than the time to run the final
script.
I think it is pointless to try to invent new semi-cryptographic
protection for the sequence numbers as it most likely will be
trivially broken when someone starts to really look at in. I am no
cryptographer, and even I could break last two tries, and even if you
manage make method I cannot break, I am sure real cryptographers can
break it in no time.
If we want to use cryptographic strong hash/mac, we need to use real
cryptographic strong hashes / macs, not try to invent something
ourselves. And we already have cryptographic strong ICV there, so lets
use that instead.
(Yes, I know the script is not very pretty and it is a hack, and it
uses rand() to generate random numbers, but as for this testing I just
needed some random packets, so no cryptographically strong randomess
was actually needed).
#!/usr/pkg/bin/perl -w
# -*- perl -*-
##
# song-crack.pl -- Crack to draft-song-ipsecme-seq-icv
# Copyright (c) 2013 Tero Kivinen
# All Rights Reserved.
##
# Program: song-crack.pl
# $Source: $
# Author : $Author: kivinen $
#
# (C) Tero Kivinen 2013
#
# Creation : 16:04 Oct 9 2013 kivinen
# Last Modification : 17:34 Oct 9 2013 kivinen
# Last check in : $Date: $
# Revision number : $Revision: $
# State : $State: Exp $
# Version : 1.35
# Edit time : 74 min
#
# Description : Crack draft-song-ipsecme-seq-icv-01
#
# $Log: $
#
#
#
##
# initialization
require 5.002;
# Secret key we are trying to guess, this is only used to
# calculate proper values for the SEQ-ICV
$k = "RandomKey123";
($k1, $k2, $k3) = unpack("NNN", $k);
# Initial sequence number for packets, after this we just use
# next sequence number.
$seq = int(rand(0x1)) * 0x1 + int(rand(0x1));
# How many packets and how long it takes to run this script.
$packets = 0;
$start = time();
# Internal state of the cracking, i.e. this is the key
# we are trying now.
$Crack::k1 = 0;
$Crack::k2 = 0;
$Crack::k3 = 0;
# Packets we have already seen, every time we find new guess
# for the key, we go through all of these and verify
# the key works for them too.
@Crack::seqs = ();
@Crack::icv1 = ();
@Crack::icv2 = ();
@Crack::icv3 = ();
@Crack::seq_icv = ();
# Which byte we are trying to crack, and how many proper
# packets we have already found for that.
$Crack::byte = 0;
$Crack::found = 0;
# Limit how many packets we check before we assume this key is ok.
# Note, that this code does not go back incrementing the earlier bytes
# if we do not find key, so setting this too low will cause the
# script not to find key. Setting this lower will require less packets.
$Crack::limit = 10;
# Loop until we have cracked the whole key.
while ($Crack::byte < 4) {
# Generate packet, i.e. genereate random ICV and calculate SEQ-ICV
printf("Packet %d, finding byte %d\n", $seq, $Crack::byte);
$icv = pack("n6", int(rand(0x1)), int(rand(0x1)),
int(rand(0x1)), int(rand(0x1)),
int(rand(0x1)), int(rand(0x1)));
($icv1, $icv2, $icv3) = unpack("NNN", $icv);
$seq_icv = $seq + $icv1) & 0x) ^ $k1) +
((($seq + $icv2) & 0x) ^ $k2) +
((($seq + $icv3) & 0x) ^ $k3)) & 0x;
printf("ICV = %s, seq_icv = %08x\n", unpack("H*", $icv), $seq_icv);
# Give that SEQ, ICV, and SEQ-ICV to the cracking engine
try_crack($seq, $icv1, $icv2, $icv3, $seq_icv);
# Move to next packet
$seq++;
$packets++
}
# Print out the results
printf("Found key in %d packets, %d seconds\n", $packets
[IPsec] Comments to draft-mao-ipsecme-ad-vpn-protocol-02
I tried to read this before the interm meeting, but found out that it would require me to read it trough several times before I could really understand it. The basic architecture is simple, we have some trusted third party, ADS which stores all information and ADC devices talk to it and gets some information from there. What that information is and how it is used is not that clear, as it would require to understand what is in each of the payloads and how they are used, i.e. it would require some more time to try to decode what is done in each operation. One question is how is the trust between ADS and ADC creted, how it is protected, and how is it authenticated. As far as I can see from the draft, it says it is outside the scope, i.e. I assume it would need to be configured in ADCs manually. This also creates single point of failure, i.e. if the ADS goes down nothing really works. Old connections stay up, but creating new ones ends up problems. Also using the private-IP address as identity for the ADC might not be that good idea. In section 4 before going to the actual protocol exchanges it would be nice to have some description about the payloads involved. It is hard to understand what "Client Information Registration" does when you do not have any idea what is in the CIDHdr or CI. Adding bit more description in there explaining that for example CIDHdr contains the Client Private Address, which is used to identify the ADC in the messages. Also in the fixed header there is type field, but I have no idea what kind of message is containe for example in the Delete Request. I.e. is there CIHdr or SEssHdr there next? What is the meaning of it etc. As currently written the draft is quite hard to understand, and would most likely require several rereads to be able to really understand how it works. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details
On Oct 9, 2013, at 5:12 PM, Michael Richardson wrote: > > Michael Richardson wrote: >>> The call-in details are: >>> Tele: +1 712-775-7400 >>> Code: 809604# > >mcr> Two LD suppliers (entirely different phones) tell me that I can not > reach >mcr> this number from my line. > > I wonder if this exchange has an inflated LD rate? > Nice if there was a SIP option to reach them how does that ENUM RR work > again :-) > >mcr> I'm gonna try Google Talk now. > > GoogleTalk connected. As does Skype ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
Paul Wouters writes: > On Wed, 9 Oct 2013, Tero Kivinen wrote: > > > For example the > > > > o Check message validity - in particular, check whether values of > > Fragment Number and Total Fragments in Encrypted Fragment Payload > > are valid. If not - message MUST be silently discarded. > > > > should be changed to say: > > > > o Check message validity - in particular, check whether values of > > Fragment Number (must be <= Total Fragments) and Total Fragments > > (must be >= previously seen Total Fragments for this message) in > > Encrypted Fragment Payload are valid. If not - message MUST be > > silently discarded. > > > > It should clearly say that if Total Fragments is less than previously > > seen then this fragment needs to be discarded. > > But you must only do that after the decryption/authentication of the > fragment or we are back at square one with an easy DoS this whole > mechanism was supposed to protect us from. We can drop the packets which have Total Fragments less than previously seen authenticated fragment. To drop packets in the queue, or update the total fragments value needs to be done only based on the authenticated packet, and the document already had those steps after ICV verification, so it already did that correctly. The document was just not really explaining what the message validity checks done in the first bullet point. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Slides for DMVPN
https://www.dropbox.com/s/yn5z2n3284c0rii/draft-detienne-dmvpn-00.pdf ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] NUDGE: Reviewing the AD VPN drafts
Hi Yoav, Thanks indeed for your comments! Please find additional [Fred] comments inline. On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) wrote: > Hi Yoav, > > Thanks for your comments. I would try adding clarity to some of these > inline [Manish] to supplement what Mike said. > > Manish > > > On 03/10/13 12:14 AM, "Yoav Nir" wrote: > >> Hi >> >> I have read the DM-VPN draft. I would not call my reading a review, as it >> was quite superficial, but here's some thoughts: >> >> - I have to admit that I'm still having trouble wrapping my head around >> some of the concepts. I understand domain-based and route-pased VPNs, as >> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >> endpoints as actually being on the same network. In fact I always thought >> of VPN as an abstract concept or as a bunch of tunnels, not as a real >> network. Having said that, I'm still trying to get used to the idea of >> NHRP being used for discovery (and to the idea of NHRP itself). To my >> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve as >> a good model for a VPN. > > [Manish]: What the applications running over the VPN see a VPN as (NBMA or > otherwise), depends a lot on the services provided on the VPN and the > draft doesn't preclude any possibilities that way. > RFC 4301 already prescribes the arms and ammunitions needed to protect IP > packets (when used in connection with GRE can be used to protect IP > multicast as well as non-IP packets) over untrusted networks. Also, as > appropriately noted in the requirements document, 4301 is silent on the > way the IPSec databases are populated. So the problem is essentially of > discovery and resolution. The discovery can be left to the routing > protocol but the resolution would still be needed unless IGPs are > multi-protocol, which they typically aren't. Even if they were, this would > need a next-hop preservation which won't scale. So, essentially DMVPN > picks up an appropriate address resolution protocol in NHRP which is > enhanced to support both discovery and resolution. This is combined with > GRE to make sure IP multicast and non-IP packets can be seamlessly(without > changing any other layer/protocol) carried across the same tunnel and also > to simplify the SPDs. [Fred] I would add that any forwarding database is good as long as it meets the security requirements of the administrator. Routing tables are used for the description but policy routing can be used too… VRF's or routing context are frequently used in practice as well. There are not "pure" routing tables anymore. When it comes to L2 forwarding, the SPD today does not even fit anymore and a total revamp would be necessary. By decoupling the output tunnel selection (or next-hop selection) from the IPsec policy, we can take advantage of various forwarding policy engines. >> - I like how the process described in section 4.3 to 4.6 quickly >> converges. If host a behind gateway A sends packets to host e behind >> gateway E, and the packets travel though the tunnels AB, BC, CD, and DE, >> then the discovery process might go through several hops, but the next >> tunnel to be set up is AE. There is no case of setting up AC or AD. >> - Reading section 4.8, I see that within a single DM-VPN, there is a >> natural progression from hub&spoke to mesh. There doesn't seem to be a >> place for policy on whether a shortcut should or should not be >> established. The resolution request is forwarded until the egress node. >> So if, for example, you have two government agencies, each with its own >> set of gateways, and two gateways (one belonging to each agency) have a >> tunnel between them, there are two possible configurations: a single >> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >> interdomain tunnel endpoints are egress nodes on their respective >> DM-VPNs. Is there a way to implement a policy so that some shortcuts are >> created between those other gateways? >> - Section 4.10 seems to be missing something. Suppose gateway A is >> forwarding traffic to gateway B, and receives an Indirection >> notification. So A sends a Resolution request. After a while, it receives >> a Resolution reply with TunS2 and PubS2 addresses. So now A should open a >> tunnel with TunS2 (right? I'm not clear about the fields). So section >> 4.10 says that authentication between these two nodes will be done using >> certificates. Considering that A has only just heard of TunS2's >> existence, what fields are there going to be in the certificate that will >> let A know that this is indeed TunS2? While a single domain might have >> some convention for this, AD-VPN is supposed to be good for multiple >> administrative domains, so there should be some rule about this. [Fred] We link the tunnel to an IKE profile. This IKE profile turns contains the identity, identity filter, certificate and certificate filter to send to and to accept from the remote p
[IPsec] Update to RFC4307 too?
While we are updating the algorithm requirements for the ESP and AH, I think we should also update the RFC4307 too at the same time, as a separate document. I think the changes we would like to do there are: Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD. Upgrade Diffie-Hellman group 14 (2048-bits) from SHOULD+ to MUST. Downgrade ENCR_3DES from MUST- to MAY Fix ENCR_NULL from MAY to MUST NOT (already MUST NOT in errata) Upgrade ENCR_AES_CBC from SHOULD+ to MUST Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to SHOULD. Downgrade AUTH_AES_XCBC_96 from SHOULD+ to SHOULD. Then we might want to think whether we want to add new algorithms, i.e. "AES_GCM with a 8/12/16 octect ICV", PRF_HMAC_SHA2_256/384/512, or AUTH_HMAC_SHA2_256_128/384_192/512_256. In all of those I think we might want to pick one length and make that SHOULD... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Minutes from the Virtual Interim WG meeting, 2013-10-09
Are at http://www.ietf.org/proceedings/interim/2013/10/09/ipsecme/minutes/minutes-interim-2013-ipsecme-2 And a recording is at http://www.vpnc.org/ipsecme-virtual-interim-2013-10-09.mp3 Participants: please let me know if I messed up any of the notes Everyone: if you want to comment on anything in the presentations, start a new mailing list thread with a useful Subject: line; don't reply to this message. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
I also think that PMTU discovery isn't very useful for IKE. That's why it is MAY. That does not help implementors who still have to implement the MAY's. if even you as a document author does not think it is veru usefil, then I think it should just not be in the document. Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not useful for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram size that is not fragmented by IP level. In IKE its the goal is different - to find _some_reasonable_ IP datagram size that is not fragmented by IP. If we have the size that is guaranteed to not be fragmented, no PMTU discovery will be needed. As far as I understand, for IPv6 it is 1280 bytes. But as far as I know, there's no such value for IPv4. If we mandate (or recommend) using really small value e.g. 128 bytes, than the perfomance will suffer badly, so it it not a good option. I'm especially worring about network I'm not familiar with - mobile networks or other constrained environments. It would be great if some experts in such networks could clarify this. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-fragmentation-03.txt
Hi Tero, Valery Smyslov writes: There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number and Total Fragments. But Total Fragments field plays a dual role if peer uses PMTU discovery - i.e. tries several fragment sizes. In this case Total Fragments allows to distinguish between fragments from different sets (assuming that trying smaller fragment size results in increasing number of fragments). This was the thing that confiused me when reading the document. The section 2.5 should explain the Total Fragments much better. I.e. change the definition something like: o Total Fragments (2 octets) - number of fragments original message was divided into. If original message is resent with different fragmentation boundaries this value MUST be larger than the previously used Total Fragments value, i.e the responder will use this to detect whether the incoming message belongs to the group of packets fragmented in same way. This field MUST NOT be zero. Or something like that. OK. Also I do not understand why the Fragment Number and Total Fragments start from 1. I think it would be more logical to have first fragment be 0, second 1, and the Total Fragments would be The Last Fragment# field. That way we do not need to have special check that fragment needs to be ignored if Fragment Number or Total Fragments are 0. That's a matter of taste. Actually, I wanted to leave one special value - zero, just in case the protocol needs to be extended in the future. I have currently no idea how it can be extended (if ever), but anyway it is a good practice in protocol design to leave this possibility. In general I think the sending and receiving rules should be explained a bit more. For example the o Check message validity - in particular, check whether values of Fragment Number and Total Fragments in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. should be changed to say: o Check message validity - in particular, check whether values of Fragment Number (must be <= Total Fragments) and Total Fragments (must be >= previously seen Total Fragments for this message) in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. OK. It should clearly say that if Total Fragments is less than previously seen then this fragment needs to be discarded. Now when I am reading th text several times through I see that all the required things are there, but when I was reading it first time through it was really hard to parse what is going on, and especially as I missed the dual role of the Total Fragments I got confused. It might be enough to just add more text in the Total Fragments description, clearly stating that it has dual role, i.e. telling what is the max fragment number of this message, and to separate the different fragmentation boundaries. My text above does not yet properly describe that either, so some better text is needed. OK, I'll try to explain in more details. Thanks, Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
I also think that PMTU discovery isn't very useful for IKE. That's why it is MAY. That does not help implementors who still have to implement the MAY's. if even you as a document author does not think it is veru usefil, then I think it should just not be in the document. Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not useful for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram size that is not fragmented by IP level. In IKE its the goal is different - to find _some_reasonable_ IP datagram size that is not fragmented by IP. If we have the size that is guaranteed to not be fragmented, no PMTU discovery will be needed. As far as I understand, for IPv6 it is 1280 bytes. But as far as I know, there's no such value for IPv4. If we mandate (or recommend) using really small value e.g. 128 bytes, than the perfomance will suffer badly, so it it not a good option. I'm especially worring about network I'm not familiar with - mobile networks or other constrained environments. It would be great if some experts in such networks could clarify this. I'm even more worried that if we use small fragments, reliability will deteriorate. Because we do not have per-packet acknowledgement, and so if any fragment is dropped, the whole message must be resent. This is probably a greater risk in mobile networks. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
Hi Paul, o Check message validity - in particular, check whether values of Fragment Number and Total Fragments in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. should be changed to say: o Check message validity - in particular, check whether values of Fragment Number (must be <= Total Fragments) and Total Fragments (must be >= previously seen Total Fragments for this message) in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. It should clearly say that if Total Fragments is less than previously seen then this fragment needs to be discarded. But you must only do that after the decryption/authentication of the fragment or we are back at square one with an easy DoS this whole mechanism was supposed to protect us from. Which of course means an attacker can just send crap faster that you can verify it is crap after performing crypto on the fragment. Not necessary. It depends on the state receiver currently is in. When you receive very first fragment and start reassembly you remember its Total Fragments field (of course after you validate message). After that you have the following possibilities. 1. You receive fragment with the same Total Fragments.You continue reassembling, adding this fragment to the queue, or discarding it if it is a duplicate packet 2. You receive fragment with the smaller Total Fragments. It may either be a late packet from the previous set of fragments (larger in size) that accidently reach us, or it may be attack packet, or it may be packet from broken peer. In any case it is safe to discard it without any verification. 3. You receive fragment with greater Total Fragments. In this case, if you already successfully reassembled message and send a response, it most probably means that response didn't reach peer. In this case it is safe to retransmit response without any verification of fragment authenticity, it won't hurt peer even if it was faked fragment. You may rate limit such responses or you may verify fragment before - as you wish. And if you support PMTU discovery, you may refragment response into smaller fragments, but in this case it is better to verify fragment before, as refragmentation cost is not zero. If you still in the process of reassembling, than yes, you need to verify fragment and, if it is valid, discard all received so far fragments and start reassembling over, as it becomes clear that peer decreased fragmen size and retransmits new set of fragments, so its pointless for you to wait for the rest of fragments from previous set. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not useful for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram size that is not fragmented by IP level. In IKE its the goal is different - to find _some_reasonable_ IP datagram size that is not fragmented by IP. If we have the size that is guaranteed to not be fragmented, no PMTU discovery will be needed. As far as I understand, for IPv6 it is 1280 bytes. But as far as I know, there's no such value for IPv4. If we mandate (or recommend) using really small value e.g. 128 bytes, than the perfomance will suffer badly, so it it not a good option. I'm especially worring about network I'm not familiar with - mobile networks or other constrained environments. It would be great if some experts in such networks could clarify this. I'm even more worried that if we use small fragments, reliability will deteriorate. Because we do not have per-packet acknowledgement, and so if any fragment is dropped, the whole message must be resent. This is probably a greater risk in mobile networks. Yes, a good point. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
