Subject: RE: [Mip6] comments about draft-ietf-mip6-ikev2-ipsec-03.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 21 Oct 2005 12:59:20 -0400

>    from what I remember, it was made optional because there is
 >    replay protection through BU sequence number. so I have to
 >    disagree. its a 32 bit sequence number. takes a long time
 >    to wrap around.
 >    
 > => two messages... not so a long time! The BU sequence 
 > number is *not*
 > an anti-replay feature at all. Please trust me.

=> FWIW, that's correct. The seq no in the BU was never intended
to be an anti-replay protection mechanism. All it does is set
an acceptable window for the next BU. It's used to ensure 
"ordering" of packets. 

Hesham

 >    
 >    >    >  In 5 page 8:
 >    >    > 
 >    >    >    This section describes the SPD and SAD entries 
 > that can be used to
 >    >    > 
 >    >    > => I propose to add something explaining here and 
 > in section 6 that
 >    >    > the care-of address is the primary care-of 
 > address. BTW this is required
 >    >    > from time to time and it makes the code for 
 > tracking and updating SPD/SAD
 >    >    > far easier to write.
 >    >    
 >    >    I dont think I understand. are you saying the MN should
 >    >    use its primary CoA and not any CoA?
 >    > 
 >    > => yes, IMHO the level for using the primary CoA in 
 > place of any CoA
 >    > is in some cases MUST and in all cases at least a 
 > SHOULD. The RFC 3775
 >    > is a bit lax about this (it uses "the CoA" for 
 > instance) but here I propose
 >    > to be clear.
 >    > 
 >    >    what if the monami6
 >    >    WG extends MIPv6 registrations to include multiple CoAs?
 >    > 
 >    > => this will be the job of the monami6 WG to produce 
 > the proper guidelines.
 >    > 
 >    >    I would like to support that with just one SA.
 >    >    
 >    > => I agree (I even suggested this with the multiple MR 
 > document as you'll
 >    > be able to see when it will be published :-).
 >    
 >    I prefer the looser text so that others can extend it to
 >    support multiple CoAs. otherwise monami6 WG has to
 >    specifically say "RFC 3775 says blah blah.. but.. but we
 >    have to relax the blah blah.. requirement".
 >    
 > => to mess the any CoA/primary CoA issue won't help monami6 
 > WG at all:
 > this can change the choice between the primary CoA and the extra CoA
 > in a choice between a CoA in the whole set of possible CoA, 
 > so anything
 > based on addresses will fail from time to time.
 > I insist!
 > 
 >    >    >  In 5.4 page 11 I can't see a trace of the 
 > protocol=MH option...
 >    >    
 >    >    5.4 is about payload traffic. that means protocol = 'any'.
 >    >    
 >    > => so perhaps we should add a subsection here to 
 > explain how to do
 >    > the protocol=MH option (which is easier than the "any" 
 > because it is
 >    > not equivalent to a transport mode applied to a 
 > tunnel). Note I have
 >    > the same concern about 6.1.4 (where currently proto = X ?! :-).
 >    
 >    I made a mistake in my earlier mail. it shouldnt have been 'any'.
 >    it should have been 'X', which 'X' stands for a particular
 >    protocol. perhaps thats enough?
 >    
 > => no, X and 'any' are not equivalent. And here the 
 > selection must include
 > the HoT/HoTI MH type (so proto must include MH, i.e., X=MH or 'any').
 > 
 >    how about
 >    
 >        The TSi and
 >        TSr payloads in the above examples will contain many 
 > other selectors
 >        apart from home_address_1.  For the sake of brevity, 
 > we show only
 >        those values that relevant for Mobile IPv6.
 >    
 > => good (so the idea is now cleary that unbounded sharing is 
 > allowed).
 > 
 >    > IMHO this is correct as it is fully equivalent but:
 >    >  - SPD-S entries are symmetrical so there is only one 
 > for MN and one for the HA
 >    >  - proto is any, not X
 >    >  - the second SPD-S entry for the MN should have the 
 > same layout than others
 >    >    (in fact it is the same than the first one as it 
 > should be only one entry)
 >    >  - s/coa/.../ as usual
 >    >  - we can say one can use a transport mode over the 
 > tunnel as it will give
 >    >    exactly the same layout for packets and the same 
 > selection (proto = any
 >    >    in tunnel mode for inner protocol, proto = 41 in 
 > transport mode for outer
 >    >    protocol).
 >    
 >    how about the following?
 >    
 >            mobile node SPD-S:
 >              - IF interface = IPv6 tunnel to home_agent_1 & proto = X
 >                Then use SA ESP tunnel mode
 >                                IDi = user_1, IDr = home_agent_1,
 >                                TSi = home_address_1, X, port
 >                                TSr = any, X, port
 >                                outer src addr = coa
 >                                outer dst addr = home_agent_1,
 >                                inner src addr = home_address_1
 >    
 >            home agent SPD-S:
 >              - IF interface = IPv6 tunnel to home_address_1 
 > & proto = X
 >                Then use SA ESP tunnel mode
 >                                IDi = home_agent_1, IDr = user_1,
 >                                TSi = any, X, port
 >                                TSr = home_address_1, X, port
 >                                outer src addr = home_agent_1,
 >                                outer dst addr = coa,
 >                                inner dst addr = home_address_1
 >    
 > => better. I still don't understand the X, prefer expanded coa abbrev
 > and have a proposal for the transport mode over tunnel.
 > 
 >    >    why is it a bad idea? without that we cant enforce a 
 > policy where
 >    >    we want the HA to send a BAck, but not a BU.
 >    >    
 >    > => you missed the discussion about the selectors for MH:
 >    > remote_mh_type=BAck on the MN means the HA can only send BAck.
 >    
 >    hmm... I followed the discussion on the IPsec mailing list.
 >    it seemed like not everybody agreed.
 >    
 > => there was no real objection but I agree this interpretation is not
 > yet in the documents (but here I believe we can forward 
 > without waiting
 > for a new 2401bis).
 > About the one SA pair, IMHO the main benefit of the fine 
 > grain selectors
 > is they make possible to put the IKE daemon on the HA is the 
 > "passive"
 > mode, i.e., it is never an initiator. This was not true (and 
 > is still not
 > true with coarse grain selectors) before because of the MN-MN case.
 > 
 >    >    >    After the IKE_AUTH exchange completes, the 
 > mobile node initiates
 >    >    >    CREATE_CHILD_SA exchanges to negotiate 
 > additional security
 >    >    >    associations for protecting Return Routability 
 > signaling, Mobile
 >    >    >    Prefix Discovery messages and optionally 
 > payload traffic.
 >    >    > 
 >    >    > => I propose:
 >    >    > 
 >    >    >    After the IKE_AUTH exchange completes, the 
 > mobile node initiates
 >    >    >    CREATE_CHILD_SA exchanges to negotiate 
 > additional security
 >    >    >    associations for protecting Return Routability 
 > signaling or
 >    >    >    optionally payload traffic, and Mobile Prefix 
 > Discovery messages.
 >    >    
 >    >    whats the difference?
 >    >    
 >    > => X and Y and Z != (X or Z) and Y...
 >    > RR (X) and payload (Z) are alternatives.
 >    
 >    the current requirements say the MN must create security
 >    associations to protect RR and MPD messages. payload is
 >    optional. this assumes the payload does not include
 >    RR messages.
 >    
 > => argh! I can see where we disagree: I assume than payload means
 > all payloads. I have not the time now but we should get the original
 > text to see who is right... Of course the other TSx stuff 
 > applies here.
 > 
 >    > => IMHO this discussion is not at the right place: it 
 > is not a MIPv6
 >    > issue but an IPsec issue. So my concern is we should 
 > restrict ourselves
 >    > to the current IKEv2/2401bis and not rely on still in 
 > discussion extensions.
 >    
 >    lets see what the IESG says about this.
 >    
 > => a dangerous way to solve our problems... (:-).
 > 
 > Thanks
 > 
 > [email-masked]
 > 
 > 
 > _______________________________________________
 > Mip6 mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mip6
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6