Subject: [Mip6] issue 76: Alt CoA should not be used when traversing IPv4 NAT

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 21 Sep 2006 03:49:21 -0700

Issue description:
------------------

The draft implicitly reuses altCoA as specified in RFC 3775.

As a result, in an IPv4 NAT traversal situation, the altCoA option will
be
present with the mapped address containing the IPv4 address on the MN
side of
the NAT.

And the HA will use that address as opposed to the source of the packet
to
respond, as mandated by MIP6.

We need to make sure that the HA answers to the IPv4 address that is
found as
source of the BU regardless of the altCoA option. 

It might be better to completely omit the option in an IPv4 traversal
situation.

Analysis:
---------

The text above requests the relaxation of the requirements on the BU
message, which currently mandates the use of the alt-CoA option when ESP
is used, for a BU sent to the HA. 
RFC 3775 does not require the alt-CoA for BUs protected by AH as the
protection covers the entire packet. 

Unfortunately, the Checksum field in the MH does not cover the CoA
either :(, which would have offered some protection. 

Conclusion (Accept issue):
--------------------------

During the last meeting at least 3 people spoke in favour of the
suggestion in this issue. Both Ryuji and Vijay agreed that RFC 3775
should be relaxed for the BU, in addition to Pascal, who raised the
issue. 

The removal of the Alt-CoA poses a threat: a MITM could modify the src
address which would result in stealing the MN's traffic. In order to
relax the requirements in 3775, while maintaining adequate security we
can proceed with two options:

 Option 1:
 In this option we remove the alt-CoA in the BU, but add another
checksum field that can be   
 used to verfiy the CoA in the src address. This field can be included
in one of the new    
 options in the draft or in a new option. Obviously we would still allow
the use of AH as in 
 3775.

 Option 2: 
 Require the use of AH for the BU. This option essentially requires that
AH is used   
 exclusively with DSMIP. 

Please express your views on which option is preferred and whether you
agree with the conclusion. 

Hesham

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 26 Sep 2006 07:53:35 -0700

Folks, 

I haven't heard any new opinions on this issue. Given that, I suggest we
go with what was already said: Relax 3775. I would suggest option 1
below in order to maintain reasonable security with ESP. If there are no
objections I'll send text. 

Hesham 

 > -----Original Message-----
 > From: Soliman, Hesham 
 > Sent: Thursday, September 21, 2006 8:49 PM
 > To: [email-masked]'
 > Subject: issue 76: Alt CoA should not be used when 
 > traversing IPv4 NAT
 > 
 > 
 > 
 > Issue description:
 > ------------------
 > 
 > As a result, in an IPv4 NAT traversal situation, the altCoA 
 > option will be
 > present with the mapped address containing the IPv4 address 
 > on the MN side of
 > the NAT.
 > 
 > And the HA will use that address as opposed to the source of 
 > the packet to
 > We need to make sure that the HA answers to the IPv4 address 
 > that is found as
 > It might be better to completely omit the option in an IPv4 
 > traversal situation.
 > 
 > Analysis:
 > ---------
 > 
 > The text above requests the relaxation of the requirements 
 > on the BU message, which currently mandates the use of the 
 > alt-CoA option when ESP is used, for a BU sent to the HA. 
 > RFC 3775 does not require the alt-CoA for BUs protected by 
 > AH as the protection covers the entire packet. 
 > 
 > Unfortunately, the Checksum field in the MH does not cover 
 > the CoA either :(, which would have offered some protection. 
 > 
 > During the last meeting at least 3 people spoke in favour of 
 > the suggestion in this issue. Both Ryuji and Vijay agreed 
 > that RFC 3775 should be relaxed for the BU, in addition to 
 > Pascal, who raised the issue. 
 > 
 > The removal of the Alt-CoA poses a threat: a MITM could 
 > modify the src address which would result in stealing the 
 > MN's traffic. In order to relax the requirements in 3775, 
 > while maintaining adequate security we can proceed with two options:
 > 
 >  Option 1:
 >  In this option we remove the alt-CoA in the BU, but add 
 > another checksum field that can be   
 >  used to verfiy the CoA in the src address. This field can 
 > be included in one of the new    
 >  options in the draft or in a new option. Obviously we would 
 > still allow the use of AH as in 
 >  3775.
 > 
 >  Option 2: 
 >  Require the use of AH for the BU. This option essentially 
 > requires that AH is used   
 >  exclusively with DSMIP. 
 > 
 > 
 > Please express your views on which option is preferred and 
 > whether you agree with the conclusion. 
 > 
 > Hesham

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 28 Sep 2006 06:51:37 -0700

Suggested text below to update this issue. I think this issue is ready
to be closed as accepted with the text below. 
 
Issue description:
------------------

Analysis:
---------

can proceed as follows:

We remove the alt-CoA in the BU, but add another checksum field that can
be   
used to verfiy the CoA in the src address. This field can be included in
one of the new    
options in the draft or in a new option. Obviously we would still allow
the use of AH as in 
3775.

Suggested text:

Add the following section to the spec:

X.X The Checksum option

The Checksum option is included in any binding update message sent from
the mobile
node to the home agent while the mobile node is located in an IPv4-only
network and protects
the binding update with IPsec ESP. This option should not be used when
the binding update
is protected with IPsec AH. This option is needed to ensure the
integrity of the care-of address in the absence of the Alternate care-of
address option. 

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Option Type    |  Option Len   |              Checksum         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type TBD

Length

Checksum 

      16-bit unsigned integer.  This field contains the checksum of the
      Mobility Header.  The checksum is calculated from the octet string
      consisting of a "pseudo-header" followed by the entire Mobility
      Header starting with the Payload Proto field.  The checksum is the
      16-bit one's complement of the one's complement sum of this
      string.

      The pseudo-header contains IPv6 header fields, as specified in
      Section 8.1 of RFC 2460.  The Next Header value used in the
      pseudo-header is 2.  The addresses used in the pseudo-header are
      the addresses that appear in the Source and Destination Address
      fields in the IPv6 packet carrying the Mobility Header.

      Note that while the mobile node is away from home, the source
address
      used for the calculation of the checksum MUST be the IPv6 Care-of
address
      in the IPv6 header. 

We also need to add text in sections 4.3 and 4.4 (mobile node and HA
operation) to require the MN to add this option and require the HA to
verify it for BUs protected with ESP. 

Comments?

Hesham