Subject: [Mip6] concensus: issue 76: Alt CoA should not be used when traversingIPv4 NAT

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 31 Oct 2006 05:10:40 -0800

Pascal, all, 

There's been a lot of emails on this issue so I think WG members are
fully informed now about what this issue involves. I will ask a simple
question and I'd like people to choose one of the options below. To
avoid any confusion I'm keeping the question simple and clear. 

Leaving the checksum option and integrity issue aside (because I know we
can fix it and I'm writing a separate issue for it) please let give me
an answer to the following question: 

Do you agree that the MN does not include the Alt-CoA option in the BU
when it is located in an IPv4-only network? 

1. Yes
2. No

Please include a brief reason for you answer, Pascal already did so I
don't expect another one :). As I said, ignore the checksum issue, this
will be handled separately.

FWIW, I choose 1) above because it's the only way to make sure that the
HA can detect the presence of a NAT by comparing the outer v4 addresses
with the IPv6 header. 

Hesham

 > -----Original Message-----
 > From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
 > Sent: Tuesday, October 31, 2006 4:12 AM
 > To: Soliman, Hesham; [email-masked]
 > Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used 
 > when traversingIPv4 NAT
 > 
 > Hi Hesham:
 > 
 > I agree:
 > 
 > 1) with relaxing the requirement in RFC 3775 to include an Alt CoA
 > option all the time.
 > 
 > 2) that the MN should omit it, as opposed to the HA filtering it out.
 > The Alt CoA is the real address at which the MN is reachable, that is
 > what HAs implement today, that is what all people in the art 
 > understand.
 > I want to stay simple and keep it that way.  I'd hate to 
 > have rules like
 > "this is A but then if there is also that then this is B which is the
 > opposite of A", etc... we are not lawyers! 
 > 
 > 3) that we have to find an alternate way to endure that the MN is
 > reachable at the CoA, defined as the source of the packet when the HA
 > gets it.
 > 
 > I'd also agree that:
 > 
 > 4) UDP is used all the time in IPv4 roaming situation, regardless on
 > whether NAT is detected or not. That's not really in the 
 > mail but since
 > you fixed the message format in the thread to add UDP, I 
 > take advantage
 > of the exchange to raise that point again.
 > 
 > I disagree:
 > 
 > 5) to jump too quickly on the conclusion that the checksum 
 > is the way to
 > go. I understand that it has value in certain scenarios that you
 > mention. But it fails to guarantee that the MN is reachable 
 > at the CoA
 > in another common case that is NAT; and it does not protect against a
 > rogue DHCP server assigning you an IPv4 DoS'ed address, which could
 > easily happen in the IPv4 world. 
 > 
 > So when you call for consensus, please leave open the 
 > solution to 3) so
 > we can see if there's a preferable alternative. I, for one, 
 > would favor
 > an approach like 2 BU flows in row, which would emulate a 3 way
 > handshake and guarantee the reachability of the MN in all cases. 
 > 
 > Pascal
 > 
 > 
 > 
 > 
 > >-----Original Message-----
 > >From: Soliman, Hesham [mailto:[email-masked]]
 > >Sent: Thursday, October 19, 2006 6:19 PM
 > >To: [email-masked]
 > >Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used when
 > traversingIPv4 NAT
 > >
 > >Folks,
 > >
 > >This issue was revived mainly due to Vijay points on the 
 > need for the
 > >checksum option when the alt-CoA is not used. Let me summarise the
 > >issues first then propose a way forward.
 > >
 > >Summary:
 > >--------
 > >
 > >The initial resolution for the issue suggested that we add 
 > a checksum
 > >option that includes a checksum on the src and dst addresses in the
 > IPv6
 > >header. This was suggested to be used when the alt-coa is 
 > not present
 > to
 > >maintain the integrity of the src address when ESP is used. 
 > I want to
 > >emphasise that this is only needed when ESP is used, not with AH.
 > >
 > >Now the point that Vijay raised is also quite valid: With NAT
 > traversal,
 > >the outer IPv4 header is vulnerable, yet it is needed because the HA
 > >responds to that address and sets up the UDP tunnel to the outer
 > >(natted) IPv4 src address in the packet containing the BU. 
 > There is no
 > >way we can secure that address, yet, it essentially acts as another
 > >binding, which if modified maliciously, would redirect the 
 > MN's packets
 > >to another IPv4 address. To be clear, here is the packet format:
 > >BU packet received by HA after passing through NAT:
 > >  IPv4 HDR (src=natted-v4, dst=HA-addr)
 > >       UDP
 > >         IPv6 HDR (src=v4-mapped-v6, dst=HA-addr)
 > >          ESP
 > >          DST-OPT
 > >          MH (BU)
 > >
 > >The HA responds with a similar packet including the BA and 
 > forwards all
 > >future packets in the UDP tunnel, with the dst address in the IPv4
 > >header being the "natted-v4" address above.
 > >So essentially protecting the BU does not protect the MN from
 > >redirection attacks in this case because the IPv4 header is 
 > vulnerable.
 > >This is an inherent problem with NAT traversal. There is practically
 > >nothing we can do about it.
 > >
 > >So the remaining question is: Is it worth worrying about 
 > the integrity
 > >of the BU in this case? IMHO I think the answer is yes. 
 > Why? Two main
 > >reasons:
 > >
 > >1. There can be cases where the BU is sent to a local HA and the
 > >operator can guarantee that no NATs are in the path. In this case we
 > >would lose integrity for no reason, i.e. the BU becomes the weakest
 > >link. This is not unusual really because an operator may 
 > decide that it
 > >will only provide the HA function within its domain, which 
 > happens to
 > >not include NATs between the MN and the HA.
 > >
 > >2. We have precedence with MIPv4 and NAT traversal where the RREQ is
 > >still secure despite the UNSAF NAT traversal.
 > >
 > >Note that the answer to 1) above may be "Use AH", but I 
 > prefer to not
 > >force that on implementations that do not do it today 
 > (although I would
 > >personally prefer AH in general for the BU).
 > >
 > >For these reasons, and there may be more, I prefer to not 
 > take this big
 > >decision to lose the integrity for the BU.
 > >
 > >Way forward:
 > >------------
 > >
 > >This issue is now closed, we all agree on it, but there may be
 > >disagreement on the checksum part. So I suggest that I 
 > generate a new
 > >issue for this discussion. Until the new issue is resolved, 
 > I won't add
 > >the checksum option to the draft.
 > >
 > >Feel free to send comments.
 > >
 > >Hesham
 > >
 > >_______________________________________________
 > >Mip6 mailing list
 > >[email-masked]
 > >https://www1.ietf.org/mailman/listinfo/mip6
 > 

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

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Wed, 1 Nov 2006 00:24:51 +0900

Hello Hesham

Yes and No.
Sorry, but it's hard to tell without concerning checksum and  
integrity issue..

It depends on how we provide integrity check to IPv4 CoA.
If there is a way to solve this, i don't mind to omit ACoA.

Otherwise, no.
We should protect IPv4 CoA by ACoA, even if it is valid only
when MN roams in global IPv4 access network.
If the src address and the IPv4 CoA in an ACoA option are different,  
HA assumes
that MN is at NATed network and ignores the address in the ACoA option.
We leave redirection attack and warns this possibility in the spec.

> can fix it and I'm writing a separate issue for it) please let give me

I am interested in how you fix this:-)

regards,
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Oct 2006 11:26:27 -0800

Soliman, Hesham wrote:
> can fix it and I'm writing a separate issue for it) 

we have a solution in the form of altCoA or
the IPv4 CoA option. don't think we need a new
solution.

please let give me
> when it is located in an IPv4-only network? 

I vote NO.

you have to include either the IPv6 altCoA option
(with the IPv4 CoA present in the mapped format)
or include the IPv4 CoA option (its not in the
DS-MIPv6 draft currently but has been proposed
on the mailing list) to carry the IPv4 CoA and
provide integrity protection when there is no NAT.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 31 Oct 2006 19:05:56 -0800

All,
I just caught up with the long list of emails on this issue. Basically,
I think 1) makes sense, since in an IPv4 network, there is no prediction
of when the packets may pass through a NAT and when they may not.  

Vijay, I'm confused by your choice here. Either the tampering of a CoA
needs to be detectable or it doesn't - applying a threat model where it
is sometimes needed (i.e., when there are no NATs) and at other times a
don't care (i.e., when there are NATs) is not making any sense to me. 

That said, I'd make a couple of observations - I think detecting the
tampering of a CoA is important in all cases, regardless of whether
there is a NAT or not. But, I am not yet sure that the checksum approach
solves it the best way (checksum is certainly not a cryptographic
guarantee). I'll think about it more - at the moment, I'm not confident
enough to make that leap :) 

Thanks,
Vidya

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 11:26 AM
> To: Soliman, Hesham
> Cc: [email-masked]; Pascal Thubert (pthubert)
> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not 
> be usedwhen traversingIPv4 NAT
> 
> Soliman, Hesham wrote:
> > Pascal, all,
> > 
> > Leaving the checksum option and integrity issue aside 
> (because I know 
> > we can fix it and I'm writing a separate issue for it)
> 
> we have a solution in the form of altCoA or the IPv4 CoA 
> option. don't think we need a new solution.
> 
> please let give me
> you have to include either the IPv6 altCoA option (with the 
> IPv4 CoA present in the mapped format) or include the IPv4 
> CoA option (its not in the
> DS-MIPv6 draft currently but has been proposed on the mailing 
> list) to carry the IPv4 CoA and provide integrity protection 
> when there is no NAT.
> 
> Vijay
> 
> > don't expect another one :). As I said, ignore the checksum issue, 
> > this will be handled separately.
> > 
> > FWIW, I choose 1) above because it's the only way to make sure that 
> > the HA can detect the presence of a NAT by comparing the outer v4 
> > addresses with the IPv6 header.
> > 
> > Hesham
> > 
> > 
> >  > From: Pascal Thubert (pthubert) [mailto:[email-masked]]  > 
> > Sent: Tuesday, October 31, 2006 4:12 AM  > To: Soliman, Hesham; 
> > [email-masked]  > Subject: RE: [Mip6] RE: issue 76: Alt CoA 
> should not 
> > be used  > when traversingIPv4 NAT  >  > Hi Hesham:
> >  >
> >  > I agree:
> >  >
> >  > The Alt CoA is the real address at which the MN is 
> reachable, that 
> > is  > what HAs implement today, that is what all people in 
> the art  > 
> > understand.
> >  > I want to stay simple and keep it that way.  I'd hate to  > have 
> > rules like  > "this is A but then if there is also that 
> then this is B 
> > which is the  > opposite of A", etc... we are not lawyers!
> >  >
> > > reachable at the CoA, defined as the source of the packet 
> when the 
> > HA  > gets it.
> >  >
> >  > I'd also agree that:
> >  >
> >  > 4) UDP is used all the time in IPv4 roaming situation, 
> regardless 
> > on  > whether NAT is detected or not. That's not really in 
> the  > mail 
> > but since  > you fixed the message format in the thread to 
> add UDP, I  
> > > take advantage  > of the exchange to raise that point again.
> >  >
> >  > I disagree:
> >  >
> >  > 5) to jump too quickly on the conclusion that the checksum  > is 
> > the way to  > go. I understand that it has value in certain 
> scenarios 
> > that you  > mention. But it fails to guarantee that the MN is 
> > reachable  > at the CoA  > in another common case that is 
> NAT; and it 
> > does not protect against a  > rogue DHCP server assigning 
> you an IPv4 
> > DoS'ed address, which could  > easily happen in the IPv4 world.
> >  >
> >  > So when you call for consensus, please leave open the  > 
> solution 
> > to 3) so  > we can see if there's a preferable alternative. I, for 
> > one,  > would favor  > an approach like 2 BU flows in row, 
> which would 
> > emulate a 3 way  > handshake and guarantee the reachability 
> of the MN 
> > in all cases.
> >  >
> >  > Pascal
> >  >
> >  >
> >  >
> >  >
> >  > >From: Soliman, Hesham [mailto:[email-masked]]  > >Sent: 
> > Thursday, October 19, 2006 6:19 PM  > >To: [email-masked]  > 
> >Subject: 
> > RE: [Mip6] RE: issue 76: Alt CoA should not be used when  > 
> > traversingIPv4 NAT  > >  > >Folks,  > >  > >This issue was revived 
> > mainly due to Vijay points on the  > need for the  > 
> >checksum option 
> > when the alt-CoA is not used. Let me summarise the  > >issues first 
> > then propose a way forward.
> >  > >
> >  > >Summary:
> >  > >--------
> >  > >
> >  > >The initial resolution for the issue suggested that we add  > a 
> > checksum  > >option that includes a checksum on the src and dst 
> > addresses in the  > IPv6  > >header. This was suggested to be used 
> > when the alt-coa is  > not present  > to  > >maintain the 
> integrity of 
> > the src address when ESP is used.
> >  > I want to
> >  > >Now the point that Vijay raised is also quite valid: 
> With NAT  > 
> > traversal,  > >the outer IPv4 header is vulnerable, yet it 
> is needed 
> > because the HA  > >responds to that address and sets up the 
> UDP tunnel 
> > to the outer  > >(natted) IPv4 src address in the packet containing 
> > the BU.
> >  > There is no
> >  > >way we can secure that address, yet, it essentially acts as 
> > another  > >binding, which if modified maliciously, would 
> redirect the  
> > > MN's packets  > >to another IPv4 address. To be clear, 
> here is the 
> > packet format:
> >  > >The HA responds with a similar packet including the BA and  > 
> > forwards all  > >future packets in the UDP tunnel, with the dst 
> > address in the IPv4  > >header being the "natted-v4" address above.
> >  > >So essentially protecting the BU does not protect the 
> MN from  > 
> > >redirection attacks in this case because the IPv4 header is  > 
> > vulnerable.
> >  > >This is an inherent problem with NAT traversal. There is 
> > practically  > >nothing we can do about it.
> >  > >
> >  > >So the remaining question is: Is it worth worrying about  > the 
> > integrity  > >of the BU in this case? IMHO I think the 
> answer is yes.
> >  > Why? Two main
> >  > >reasons:
> >  > >
> > > >operator can guarantee that no NATs are in the path. In 
> this case 
> > we  > >would lose integrity for no reason, i.e. the BU becomes the 
> > weakest  > >link. This is not unusual really because an 
> operator may  
> > > decide that it  > >will only provide the HA function within its 
> > domain, which  > happens to  > >not include NATs between the MN and 
> > the HA.
> >  > >
> >  > >2. We have precedence with MIPv4 and NAT traversal 
> where the RREQ 
> > is  > >still secure despite the UNSAF NAT traversal.
> >  > >
>  > prefer 
> > to not  > >force that on implementations that do not do it today  > 
> > (although I would  > >personally prefer AH in general for the BU).
> >  > >
> >  > >For these reasons, and there may be more, I prefer to 
> not  > take 
> > this big  > >decision to lose the integrity for the BU.
> >  > >
> >  > >Way forward:
> >  > >------------
> >  > >
> >  > >This issue is now closed, we all agree on it, but there 
> may be  > 
> > >disagreement on the checksum part. So I suggest that I  > 
> generate a 
> > new  > >issue for this discussion. Until the new issue is 
> resolved,  > 
> > I won't add  > >the checksum option to the draft.
> >  > >

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 31 Oct 2006 19:48:44 -0800

well, if there is a NAT on the path the source
address on the outer IPv4 header is modified.
anytime a packet goes through a NAT, we have
this problem. this is a common problem. so I
don't think we should design a DS-MIPv6
specific mechanism to protect  an address that
is modified by the NAT. its not worth it.

when there is no NAT, the use of altCoA or the
IPv4 CoA option provides automatic integrity
protection to the care-of address. thats all.

Vijay