Re: Death to AH? (was: Reasons for AH & ESP )

[Jean-Michel COMBES <jeanmichel.combes@rd.francetelecom.fr>]

Hi, 

the main reason why the Home Address option cannot follow rather than precede an ESP header is that the HA option contains the Mobile Node's home address which is used to perform IP filtering. 
So, we have : 
             IPv6 header 
             Hop-by-Hop Options header 
             Destination Options header (with HA option) 
             Routing header 
             Fragment header 
             Authentication header 
             Encapsulating Security Payload header 
             Destination Options header                    (*) 
             upper-layer header                            (*) 

- HA option is covered by AH 
- (*) is encrypted by ESP 

Regards. 

Mohan Parthasarathy a écrit : 
> > Mohan Parthasarathy writes: 
> >  > Mobile IPv6 has introduced new IPv6 destination options which requires 
> >  > the use of AH. Section 4.4 of draft-ietf-mobileip-ipv6-12.txt 
> >  > explains the IPsec requirements. (June 8th is the deadline for 
> >  > any comments. It is to become a proposed standard). It specifically 
> >  > says ESP can't be used. 
> > 
> >    Is there any particular reason why the binding cache 
> >    update messages in the destination options cannot 
> >    follow rather than precede an ESP header? It doesn't 
> >    look to me like there is any reason to keep destination 
> >    options in the clear, in which case ESP would work 
> >    fine. 
> > 
>Binding update messages itself can appear after AH/ESP header. 
>But when used with HOME address option it should appear 
>before. Earlier revision of this draft had the home address option 
>after AH/ESP header. I don't know what made them change to put before 
>the AH/ESP header. Something relevant to this can be seen 
>in the following discussion of the ipng archives : 
>
>

http://www.wcug.wwu.edu/lists/ipng/199906/msg00042.html > >But still one could argue that AH still protects the CoA present >in the IPv6 header's source address field. (This can still be >overcome by using yet another "alternate-care-of-address" option. >This is not a MUST/SHOULD in the draft). Why is it that the >protection offered by AH to the IPv6 header's source address >field is not important ? At least i can see it useful in >this case. > >-mohan -- France Telecom R&D - DTL/SSR COMBES Jean-Michel, Internet/Intranet Security E-Mail : jeanmichel.combes@rd.francetelecom.fr Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19 PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

References:

• Re: Death to AH? (was: Reasons for AH & ESP )
• From: Mohan Parthasarathy <mohanp@locked.eng.sun.com>

---

• Prev by Date: Re: RESPONDER-LIFETIME Notify question
• Next by Date: Replay problem
• Prev by thread: Re: Death to AH? (was: Reasons for AH & ESP )
• Next by thread: Re: Reasons for AH & ESP
• Index(es):
  • Main
  • Thread