That's such answer * *I was looking for :) I am running 12.14(15)T because we'll be tested on this version (at least that was the last info I had about exam IOS version). I was concerned with that answer with fragmentation since we do have commands to treat them.
Thanks Piotr for such research and now it makes sense. :D On Fri, Jan 7, 2011 at 4:30 PM, Piotr Matusiak <[email protected]> wrote: > Guys, > > I did a deeper research and now know the truth :) > > The AM with certificates: > 1. Is NOT possible by design with EasyVPN deployment > 2. It IS possible with other deployments like SVTI or GREoIPSec (using > ISAKMP profiles) > > I checked and it seems this is working on 12.4(24)T and above. It is NOT > working with 12.4(15)T. > > The primary reason for NOT allowing certificate authentication with AM is > security. AM in general is not recommended and if someone has invested in > PKI already there is no reason for decreasing security enabling AM. The > problem with fragmentation is not so important. Actually, nowadays most of > MM with certificates have MM#5 and MM#6 fragmented. > > Hope this helps! > > > Regards, > Piotr > > > 2011/1/7 Bruno <[email protected]> > >> thanks for saving me some time researching out there. >> >> Is there any disadvantage of one over the other? >> >> So, if there are ways of fragment either ipsec or isakmp, what is the >> fragmentation issue we might see when using packets too large with IPSEC >> implementations? >> >> >> On Fri, Jan 7, 2011 at 10:03 AM, Kingsley Charles < >> [email protected]> wrote: >> >>> For IPSec, the fragmentation can be done before or after fragmentation. >>> >>> router(config)#crypto ipsec fragmentation ? >>> after-encryption Perform fragmentation of large packets after IPSec >>> encapsulation. >>> before-encryption Perform fragmentation of large packets before IPSec >>> encapsulation. >>> >>> For ISAKMP, it should be done automatically based on mtu size as it is >>> being transported over UDP. >>> >>> >>> With regards >>> Kings >>> >>> >>> >>> On Fri, Jan 7, 2011 at 5:11 PM, Bruno <[email protected]> wrote: >>> >>>> Yeah, gotcha! >>>> >>>> So the problem here is fragmentation. I need to read some points of RFC >>>> to understand how fragmentations goes on IPSEC as I haven`t read anything >>>> yet. I thought router had something to handle such thing with the command >>>> "crypto isakmp fragmentation". I gotta understand what does this command >>>> >>>> Thanks Piotr. >>>> >>>> On Fri, Jan 7, 2011 at 9:22 AM, Piotr Matusiak <[email protected]> wrote: >>>> >>>>> Bruno, >>>>> >>>>> The problem with AM is that it does not provide Identity protection (as >>>>> this info is in clear text) and may cause DoS issues because the responder >>>>> must generate KE material to send back to the initiator. >>>>> >>>>> I'm not saying that KE is protected in MM, the problem is with >>>>> fragmentation. If you want to send all those information in one packet >>>>> this >>>>> may be an issue. In MM you're sending the same info in 3 different packets >>>>> (#1,#3,#5) from the Initiator perspective. In AM you must send it at once, >>>>> so that Proposals+KE+Identity(if it is certificate) may be a way larger >>>>> than >>>>> 1500 bytes (or 1300 as it is sometimes configured on the IPSec Client). >>>>> >>>>> >>>>> Regards, >>>>> Piotr >>>>> >>>>> >>>>> 2011/1/7 Bruno <[email protected]> >>>>> >>>>>> Sure it does. Thanks Piotr. >>>>>> >>>>>> Which fragmentation issue could be seen? I didn`t think about it so >>>>>> far and have no clue why it would be a problem >>>>>> >>>>>> For instance, the cisco vpn client for whatever new connection, if you >>>>>> debug on the server side, we could see lots of proposals being sent. It >>>>>> seems it tries all possibilities. >>>>>> Wouldn`t it fall to fragmentation issue you referred? >>>>>> >>>>>> About security, as per my understanding, using RSA certificates, isn`t >>>>>> true that the attacker should get more informations to be able to guess >>>>>> the >>>>>> DH shared key? >>>>>> Even though it sends the Key material (in general goes in the 3rd and >>>>>> 4th message in MM and it goes in plain text as well) we would loose a lot >>>>>> using pre-shared key maybe with AG then with certificates. >>>>>> >>>>>> Well, sorry if the text got confused. Just tried to understand your >>>>>> points and discuss then >>>>>> >>>>>> >>>>>> On Fri, Jan 7, 2011 at 8:16 AM, Piotr Matusiak <[email protected]>wrote: >>>>>> >>>>>>> Gents, >>>>>>> >>>>>>> Let me chime in and add something to the discussion. >>>>>>> >>>>>>> Although it would be possible to use certificates with AM it brings a >>>>>>> little value in my opinion. >>>>>>> In AM everything is sent over with the very first packet including >>>>>>> Identity Payload. This means the certificate used as ID would be easily >>>>>>> accessed by everyone as this packet is not encrypted. There is no >>>>>>> identity >>>>>>> protection at all in AM. >>>>>>> >>>>>>> The main reason for Cisco not to implement certificates with AM is >>>>>>> the potential problem with fragmentation. Note that the first packet >>>>>>> contains Proposals, KE material, and Identity, so if we would use >>>>>>> certificates the packet will be way above 1500 bytes. >>>>>>> For the same reason developers must NOT include all combination of >>>>>>> proposals - the packet length must be controlled. >>>>>>> >>>>>>> >>>>>>> Hope it will bring some light to that topic. >>>>>>> >>>>>>> Regards, >>>>>>> Piotr >>>>>>> >>>>>>> 2011/1/7 Bruno <[email protected]> >>>>>>> >>>>>>> Yeah, it wouldn't work as well >>>>>>>> >>>>>>>> My main config was: >>>>>>>> >>>>>>>> crypto isakmp pol 10 >>>>>>>> auth rsa-sig >>>>>>>> crypto isakmp profile AM >>>>>>>> initiate mode aggressive >>>>>>>> crypto map CMAP 10 isakmp-profile AM >>>>>>>> >>>>>>>> This results is the IOS jumping from AM to MM. If you change the >>>>>>>> isakmp policy to pre-shared keys, it will work with AM as expected >>>>>>>> >>>>>>>> I wonder if there is any weakness that made Cisco to avoid such >>>>>>>> behavior >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 6, 2011 at 10:37 PM, Jerome Dolphin < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Woops, no it doesn't help, forget I sent anything :) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Jan 7, 2011 at 11:35 AM, Jerome Dolphin < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Does this help? >>>>>>>>>> >>>>>>>>>> http://blog.ine.com/tag/aggressive-mode/ >>>>>>>>>> >>>>>>>>>> crypto isakmp profile AGGRESSIVE >>>>>>>>>> initiate mode aggressive >>>>>>>>>> self-identity fqdn >>>>>>>>>> keyring default >>>>>>>>>> ! >>>>>>>>>> crypto map VPN isakmp-profile AGGRESSIVE >>>>>>>>>> crypto map VPN 10 ipsec-isakmp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jan 7, 2011 at 2:42 AM, Bruno <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>>> At least it was what I understood reading it >>>>>>>>>>> Take a look on the 5.1 and 5.2 topics. >>>>>>>>>>> >>>>>>>>>>> 5.1 IKE Phase 1 Authenticated With Signatures >>>>>>>>>>> 5.2 Phase 1 Authenticated With Public Key Encryption >>>>>>>>>>> >>>>>>>>>>> Within each one you'll find how it should behave in MM and AM. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Jan 6, 2011 at 1:31 PM, Vybhav Ramachandran < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello Bruno, >>>>>>>>>>>> >>>>>>>>>>>> I always thought that Digital certificates could only work in >>>>>>>>>>>> Main Mode. I'm yet to go through that RFC though.I'll go through >>>>>>>>>>>> it in a >>>>>>>>>>>> while. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> TacACK >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Bruno Fagioli (by Jaunty Jackalope) >>>>>>>>>>> Cisco Security Professional >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> For more information regarding industry leading CCIE Lab >>>>>>>>>>> training, please visit www.ipexpert.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Bruno Fagioli (by Jaunty Jackalope) >>>>>>>> Cisco Security Professional >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> For more information regarding industry leading CCIE Lab training, >>>>>>>> please visit www.ipexpert.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Bruno Fagioli (by Jaunty Jackalope) >>>>>> Cisco Security Professional >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Bruno Fagioli (by Jaunty Jackalope) >>>> Cisco Security Professional >>>> >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, >>>> please visit www.ipexpert.com >>>> >>>> >>> >> >> >> -- >> Bruno Fagioli (by Jaunty Jackalope) >> Cisco Security Professional >> > > -- Bruno Fagioli (by Jaunty Jackalope) Cisco Security Professional
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
